Improvements to mobile support

Hi,

I’m Martijn Walraven, a new core developer at Meteor. I’m also the developer of Meteor iOS, which integrates native iOS apps with the Meteor platform through DDP.

I’m currently working on some improvements to the Cordova integration that I hope to get into the Meteor 1.2 release:

  • Update Cordova to the most recent version (5.1.1) and update plugin dependencies. #4723

  • This should also make it easier for people to install the [Crosswalk plugin] (https://crosswalk-project.org/documentation/cordova/cordova_4.html), which offers a much improved web view, especially on older Android versions. #3076

  • Update ios-sim to a version that no longer relies on private Xcode APIs, which should fix problems with running the iOS Simulator. #2878

  • Switch to having developers install the Android SDK separate from Meteor. Tying the two together has made it hard to keep the development toolchain up to date and has led to some difficult to diagnose failures. This would likely mean pointing users to instructions for installing an Android SDK if they haven’t already done so. The most straightforward way is probably to install Android Studio, which offers a convenient configuration wizard on first launch. #4721

  • Add support for Android development on Windows. Our current implementation has some dependencies on OS X/Linux that I’m in the process of removing. #4155

  • Hot Code Push on mobile has some performance and reliability issues that I think we can fix by moving functionality into native code. In particular, Hot Code Push of faulty code should no longer require a reinstall of the app. #4722

If you want to chime in on any of these changes, please comment on the linked GitHub issues.

Beyond these first steps, I have other ideas for improving mobile support that I’m excited about. Some of these are related to improving the developer experience, such as better runtime error reporting. Others involve looking at integrating new technologies like React Native.

I want to make sure I understand the needs of Meteor developers, and I’d like to learn more about the way they are currently doing mobile development. So especially if you have an existing mobile app, I’d love to hear about your experiences and wishes. Please let me know what you think on this thread, or open a feature request on GitHub if you have specific suggestions.

Martijn

13 Likes

These sound absolutely awesome! I especially lke the last point regarding Hot Code Push, if that can be solved…then nothing like it!

Hi Martin,

great news, looking forward especially for crosswalk and HCP.

Me and @arjunrajjain are solving the same issue about long startup time of meteor cordova apps.

Can you provide us with some tips? How fast we can manage meteor app to start up? In my case app starts in about 7 secs and as far as i know cordova should be able to start in about 2 secs.

Thank you in advance, this is piece of pain in my work (ordinary user does not expect native (non-game etc) app to load in 7+ secs).

Best,
J

I’m not sure about the specifics of your case, but in general it might help only to subscribe to data that is needed at startup and subscribe to other data as the user navigates your app. Also, if you’re hosting on *.meteor.com, apps that haven’t been used in a while may need some time to wake up.

Another factor affecting performance could be related to Hot Code Push, but this should only happen when there have been changes. Because all assets in the /public folder are downloaded on each update, this could take some time (see known issues). I have some ideas for improving this process, but the best tip is not to store large assets as part of your app.

Thank you for the answer. More info about the app:

  • current startup time is about 11 secs. to render quite simple login page
  • there is no single subscription called at startup time (there is no need, i just want to render the login page)
  • same startup time is in the case of localhost environment (same wifi) and production env. (our own, we do not use *.meteor.com)
  • /public folder is empty/not used
  • it seems that about 6 secs it loads cordova/meteor and the another 5 secs it executes application code before login page is rendered
  • startup time was measured several times without code change so it shouldn’t be affected by HCP (we tested it with no internet connection with same results)
  • during most of time consumed by the startup ‘adb logcat’ show similar lines like this:
    “V/meteor.cordova.updater(26716): remapUri http://meteor.local/client/views/posts/modules/post_actions.js?dfd8e7a287bf11fd7cebcc1865c70a8043d55e55
    D/meteor.cordova.updater(26716): Remapping to file:///android_asset/www/application/client/views/posts/modules/post_actions.js” (it’s same in case of example apps, so i supposse this is not related to my app) - does that mean that those files are transferred from server to client? (update: according to wireshark log, during the startup time only about 10-40kB are transferred)

I tried several public meteor example apps (todos, telescope, …) and it has very similar startup times (about 10secs). Is there any way how to speed it up, which I do not see? (10 secs for regularly used appliaction is just too much, i know it can be minimized but it is something which can not be taken in to account because of phone restarts, optimizers etc)

1 Like

@martijnwalraven this sounds awesome. Stoked this is being looked at.

A few key areas for the app we’ve had live, but still in it’s infancy:

  1. Reliability - the HCP stuff sounds good. I started using https://atmospherejs.com/percolate/safe-reload and seems pretty good so far. So yes a huge plus, if a HCP solution is in the core and I can prevent a user having to re-install.

  2. Consistency across browser, iOS and Android - I have had major issues with inAppBrowser - sometimes it just crashes and you lose the ability to close the window. I am using some nasty workarounds like changing href targets and capturing on click data-something and started hitting some other inconsistencies between Cordova on Android and iOS.

Also, click on touch devices. see: Notes on Fastclick for Android devices

I am hoping Crosswalk solves a bunch of issues for me (But not sure). I have been trying to test this out via How to get Crosswalk working with Android - Step by step guide but have run into issues. If you have a how to get a pre-release version running for dummies… happy to have a go.

On iOS - I have just installed https://github.com/practicalmeteor/meteor-wkwebview so hoping that does the same for me on iOS.

Any reason Crosswalk would just not be in the core (or available via some flag/CLI)?

  1. As close to native UX as possible. With Meteor/Cordova effectively being a webUI there are some big gotchas like how those solutions deal with input fields, keyboard pop-ups etc. On my list is to relook at Famous integration to try and solve this (but really up for anything). For example, having a chat input field at the bottom of a page (with fixed position bottom toolbar) is a pretty standard UX pattern but it kinda falls apart when trying to implement in a scrolling browser window. Users bash me up about this a lot. So I’d love to see some best practices implementations of common UX patters, please.

  2. Performance of load time - yep I think others have captured this in this thread.

Thanks heaps for the heads up.

2 Likes

Hi @martijnwalraven,

Thank you for your post. It’s really awesome to see where meteor/mobile is going.

I have a particular problem with my iOS/Android app (happens mostly on Android): the app struggles and eventually crashes on poor internet connection areas (because of live data sync, I suppose).

To mitigate this, I’ve been trying to measure the network quality by permanently measuring the time it takes for a picture to be downloaded (via meteor http) from my server to the client. I then opens or closes the database accordingly (via Meteor.reconnect() or Meteor.disconnect()).

Would you recommend a better solution to cope with this?

Many thanks and keep up the good work.

Hi,

Great news that you’re going to improve the mobile side of things. Not so fantastic that I’ve just (as in today) finished rebuilding my mobile mobile app using Ionic and Angular due to some of the issues I faced with Meteor. I had seen some comments on github suggesting mobile wasn’t MDG’s focus at the moment (that’s why I jumped ship for the app) but glad that’s not the case.

Great to see hot code push being improved. My app would get stuck on the splash screen or on a white screen on Android and iOS intermittently. The only fix would be to reinstall the app and I couldn’t for the life of me find a repeatable pattern as to what was causing it. I presumed it was related to hot code push in some shape or form. It’s actually the main reason I chose to rebuild the app with Ionic/Angular and created a REST Api to my Meteor webapp.

On the topic of hot code push, it would be great if it assessed which files had actually changed and only downloaded those ones - rather than redownloading everything. I believe there’s a cordova plugin that takes this approach floating about. I’ll see if I can find the github page.

One of the main things I struggled with when making a meteor mobile app was the best way to structure everything. I eventually settled on having the mobile app as a package of my whole app. A few pitfalls with this seemed to be:

  • Because my mobile package was only included by using ‘web.cordova’ I couldn’t debug/preview it in the browser - I had to open an emulator every time
  • Having to specifically include each individual file in the package.js file - it would be great if you could specify a directory!
  • Changes to the web app causing a hot code push to the mobile app

I’d certainly find it helpful if there were an accepted pattern for this so that everyone was reading from the same page.

Stealing Ionic’s splashscreen/icon building command line tool would be a nice little addition to the meteor command line tool. So that you just specify one icon/splash image and all of the various sizes are auto generated.

Think that’s all that springs to mind at the moment but look forward to seeing all the changes you’ve mentioned :smile:

1 Like

Would love to see a new directory structure where you could put Cordova specific code into a cordova folder. Just like you can for client/server at the moment.

And would love to see integration with the JS native solutions such as React Native (as you already mentioned).

3 Likes

@martijnwalraven Native Support!

I’m using React-native, now we have a polyfill (https://github.com/hharnisc/react-native-meteor-websocket-polyfill) that we can use DDP, but is not part of Meteor, or a Meteor package that works with React-Native out of the box, like we have with Codova.

If you could have your project as a component of React-Native, eg “meteor-ios” you use in Swift, as a “native module” to React-Native, then we can have a “Native Client DDP”, and using “methods”, “subscriptions” etc. out of the box without having to create functions to “observe”, so this is already a step to offer Meteor as backend and React-Native (JS) as the client app.

Better than that only: meteor add-platform react-native. :relaxed:

Thanks any way, and I’m glad to know that you are part of core team.

2 Likes

@martijnwalraven : I request you make login on mobile with social services as easy as it is on web. On web, we can simple add {{> loginButtons}} and it works. Can we have similar for mobile? Right now, on mobile the social login open in ugly browser instead of native app.

Awesome. This would solve some of big pain points. Great improvement. I am especially interested in crosswalk and separation of android sdk.

I am super excited to read that you’re working on a windows integration!!! I also agree with removing the SDK install for meteor, it’s confusing to set up several SDKs and I think also error prone.

I cannot wait to see Windows Cordova support. I’d be willing to beta test this, since I have a web app that can/needs be ported to mobile asap.

Hi, look at https://atmospherejs.com/particle4dev/cordova-fb

Thanks for all your work on this, Martijn! Are there still plans for incorporating Android development support on Windows with 1.2 or has that been postponed?

Windows support didn’t make it into 1.2, but it should come soon after, hopefully together with another batch of Cordova improvements.

Martijn, thanks for the post!

+1 for faster startup times on iOS and Android. Can you please revisit demo apps (e.g. simple-todos) and have it tuned for best practices regarding mobile device startup times?
Simple-todos takes 7.5 secs to start up even on my iPhone 6+

I believe startup times should be a lot improved when the Hot Code Push changes land (after 1.2), but I’ll look into it some more if that doesn’t help.

Meteor noob here, thinking of a comparison to Wordpress.

To me, my big WTF arriving at Meteor, is – nobody in meteor talking about just responsive web design to cover all the things… the various devices out there.

E.G… a wordpress site I support was switched to a responsive WP theme. It has gone from “awful” to “great” to use on devices. There are really no usability issues at all… cost: zero, effort: 10 minutes.

So… why don’t I see any part of the Meteor community looking that way?

I can understand a certain “app mentality” that will appeal to a certain percentage of developers.

The “App Store” is definitely a kind of promotion. The user can be locked in, or monetized while using the device app. Plus… (scratching my head for reasons)… maybe some developers think that device users simply do not use device web browsers? Is that studied?

But that can’t be everyone here ;-).

I’d like to see Meteor follow Wordpress community and make Meteor apps “just work” in the Android, iOS, [any device here] browser by better builtin support of bootstrap themes. Or excellent integration points for theming so that third parties can come in as they do in Wordpress world.

Just a question: Is Cordova fully supported for the OS X version? At the moment, I’m using Windows 10 and want to switch to OS X for Meteor mobile development.