I’ve been building a Cordova app in Meteor, and found a few areas that could be improved.
Cordova deserves a dedicated folder. In that folder, we can tuck away all the resources, configurations, and plug-ins:
cordova/iOS/icons/*.png
cordova/iOS/splash/*.png
cordova/Android/icons/*.png
cordova/Android/splash/*.png
cordova/plugins/
cordova/main.js or w/e -- configuration
I think the icons and splash screens should have fixed file names, and be automatically detected. There is no reason why we should specify them into mobile-config.js. This would also ensure everyone is always on the same page with this stuff across the Meteorverse. Additionally, I hate having mobile-config.js and and “resources” in my text tree, and I think it’d be nicer if they were tucked away in a Cordova folder.
Here’s where things get radical: what if the Cordova folder can have its own client and assets folder? Then, we can efficiently separate the web client and the mobile client, while sharing the packages and server code.
We also need plugin detection. Something like the Packages object but for Cordova. This is important because if we hot push a new version of an app that depends on a plugin, but that plug-in is not on the app because the app wasn’t updated, it would be helpful to detect and place the necessary guards to prevent problems.
Mhhh…I think MDG should put it resources into React Native for mobile development. Cordova isn’t good for any larger / professional apps. I’ve just coded a messenger with Meteor + Cordova and on Android the app takes about 5 seconds to start (cause Meteor needs to start an internal web server) and will be killed on devices with small memory,when it goes to background.
@martijnwalraven is actually rewriting all that for the 1.3 release, fingers crossed it gets better. But beside that, Cordova has a lot of good use cases. It offers complete code reuse on IPhone, Android, etc.
+1 from me. Of course, you can detect the existence of a plugin by checking the global variable it hooked in, but I’ve experienced that there’s not a common place where plugins register. It would be much easier if there was a plugin detection mechanism in Meteor.
I don’t agree with these recommmendations. I fell in love with putting everything into my own packages, it makes life so much easier. I even re-bundle Cordova plugins in custom packages, to make it easier to plug them into my apps. I personally don’t like these “magic folders”, because you never really know where to put things correctly. And I would not want to be forced to use them.
With packages, a separation between app and web code is quite easy, since you can either import a whole package for one of the platforms or single files. This is quite neat.
This isn’t Meteor-specific, but note that you can inspect the result of cordova.require("cordova/plugin_list").metadata to detect what plugins (and what versions of plugins) are installed.
I disagree with that. Although I love the idea of React Native, I don’t want to throw away my whole app just because React is so much cooler now. That’s just the same discussion as with Blaze vs. React. Yes, React Native may be the future, but I also need some reliability for the apps I am currently developing.
Yes, startup times in Cordova are quite bad. In one of my apps, I tried to cover this by using a native page on startup. But in the end, this approach made things much more complex, so I dropped this hybrid approach in my second app. Would love to see Meteor Cordova startup faster, and I would really appreciate if MDG would invest some time into that.
IMHO, every app should be aware that it can be killed if it is been sent to the background. That’s the nature of apps, even with native ones.
BTW: Is React Native on Android ready / production ready yet?
But was Cordova really “production ready” since it exists? IMHO it is a cheap option if I’m a web developer and not much experienced in native phone development. Also I can save a lot of time because I can reuse code (like @msavin said) and work with my usual tools/workspace. This may be okay for some smaller apps without any multimedia features, but if you have a lot of photos or videos, you will run into some trouble (f.e. customize the video element - on iOS you aren’t allowed to do that).
To the memory problem: In my case, we’ve to use Cordova with Crosswalk, which increases the used RAM up to 100MB on the apps startup. This may be okay on high end devices, but makes the app uncomfortable on slower devices.
BTW: Is React Native on Android ready / production ready yet?
I’ve to say that we are trying React Native on iOS at the moment. Android support is now added, but I didn’t try it yet. We move our Cordova app over to React Native and will see if React Native is really ready for production in our case. I’ll post an update when we’ve finished all steps.
Yes and no. Of course, a native app is much better, from a performance and usability point of view. But if you have a small team (like we do), you just cannot afford implementing your app 3 times: for web-browsers, for iOS, and for Android (let alone Windows Phone and all the other mobile platforms).
With Meteor Cordova, I am able to deliver to three platforms with one code, and this is a HUGE benefit. AFAIK, even React Native does not solve this, since you have to build platform-specific React components. I see a clear benefit when it comes to usability and performance, of course. But from a development turnover point of view, Cordova is still the way to go for me. Maybe this will change as the team grows.
Yep, I know what you mean. But there’s always an option to go hybrid on Cordova. For instance, I am developing an app with video chat functionality at the moment, using a Cordova plugin. And if I need more native code, I can even build it on my own, if I want to. But I am not forced to, so I can do it only where it is actually needed.
The biggest downsides I see for Cordova is: it’s quite slow, because it’s HTML, it does not really “feel” native, and the app startup time is way too long (at least with Meteor).
But if you have a small team (like we do), you just cannot afford implementing your app 3 times: for web-browsers, for iOS, and for Android (let alone Windows Phone and all the other mobile platforms).
Yep, that’s the reason why we use Cordova, too. We’ve built our Chatroulette clone with PeerJS and Crosswalk. We didn’t use a Cordova plugin for that (I guess you use PhoneRTC?), because on my Android device PhoneRTC crashed on every call.
But let’s take a look at React Native: You can select between multiple reusable components (https://react.parts/native). It feels a little bit like “Lego” and you don’t need to worry about which mobile UI framework you have to use or to integrate with Meteor. It would be okay if MDG could release a NPM plugin which makes the use of the accounts package more comfortable with React Native. I think the guys who use React for web development have the same problem. At the moment you have to connect your app via DDP, store login tokens manually, etc.
No, this didn’t work for me either. It’s quite sad that this repo is not really maintained anymore, it looked very promising. I’m using OpenTok at the moment, but had to patch it heavily to make it work, as the Cordova plugin is also not really maintained anymore.
