Mobile about guide HOT 24 CLOSED

I hope no one minds me butting in but I feel like I could answer a few of these for you guys and give you my two cents. I've been working a fairly large mobile application for android and ios using cordova / meteor for about a year now. I've run into many issues that I've wanted a guide for, so i'm really glad you guys are starting this. Apologies for little to no formatting and the large wall of text.

2. How do you do debugging, logging, testing on iOS/Android?

Android:

• Javascript Logging / Method invokation: Chrome (via inspect devices) -- works for android 4.0+
  https://developers.google.com/web/tools/chrome-devtools/debug/remote-debugging/remote-debugging?hl=en
• Native logs - useful for finding app exceptions and viewing native plugin logs. http://developer.android.com/tools/help/monitor.html

iOS:

• Javascript Logging / Method invokation -- Safari web inspector
• Native logs -- Xcode -- Built into Xcode when you run on a device / emulator (believe you need to install cordova-plugin-console for this to work correctly).

3. How to optimize your user experience on mobile to make your app feel smooth and usable.

• If you have a large, graphically intense app, use crosswalk for android. In the future wkwebview for iOS.
• Make your buttons large, click detection on the webview is not as accurate as native
• Use Latency Compensation whenever and wherever you can, button clicks on mobile apps are expected to immediately do something.
• Install plugins one at a time, and monitor performance after each addition. One plugin that will destroy your app performance is cordova-google-maps. Use crosswalk to solve this.
• Keep animations to a bare minimum if application performance is important to you.

4. How to use native mobile features through Cordova plugins

All Cordova plugins have a Javascript interface to interact with their native counterparts.

5. How to add push notifications, intents, and other mobile operating system integrations

Usually the plugins your using handle intents and other mobile OS integration.

6. How to use hot code push effectively to update your app outside of the normal app store review process while maintaining a great user experience

This is all personal preference. There are a few packages that aim to solve this. There are three main directions i've seen people heading.

1. Wait until users go in the background to reload -- This works well, but if the user doesn't go in the background, and they are on extremely old code, it can completely break their app.
2. Prompt the user to reload via a button or popup -- This works well, with the same caveat above AND apple will reject your application if they see this behavior in the app.
3. Wait for certain conditions to be met -- I developed mirrorcell:smart-reload to solve some of these issues I was having, namely, fragmentation and random reloads. Integrating an idle tracker into the mix and forcing users to reload immediately on first start of the app helped enormously.

The best UX that i've attained for hot code pushes is to bring up the splash screen with a loading icon at the start of the migration, catch meteor startup, show the splash screen once it comes back from the migration, and then stop it once the main template has been rendered (via onRendered). That basically stops the screen from flashing white (because its native code above the web view). Would be a useful feature in hot code push 1.3.

What should people know when they are using cordova plugins? How do you know which ones work, what is the best way to search for them, etc?

*this is my experience with cordova plugins

Non Apache Cordova plugins have essentially no quality control. You will run into plugins that break on your device, with little or no error logging, sometimes you have to be prepared to dig into the native code and fix it yourself.

You also won't know if something works or not until you actually run it on an actual device (not the emulator) and plugins that work on one device may not work or even crash on another. Debugging a plugin / modifying native code is an entirely other conversation.

The key to cordova plugins is you probably are going to need to learn a small amount of obj c / swift / java if you don't want to be completely at the mercy of the plugins developer.

The best way to search for plugins now is through https://cordova.apache.org/plugins/. You can also go straight through npm. Although I'll just mention, about a quarter of the cordova plugins I use are not on NPM. For those plugins you have to find them through google, or git. Anything apache made will usually work fairly well. Even then, some plugins are a mess (looking at you cordova-plugin-media).

Do we know much about push notifications?

Raix has a great package for push notifications through meteor. It bootstraps the login system so its a piece of cake to use. https://atmospherejs.com/raix/push. To his credit, I've never had an issue with the plugin now that hes updated the push plugin to the newest version.

I'm adding this one as a request by @martijnwalraven :

How to access your /public files through cordova.

This came up because of many forum posts of people not being able to use plugins such as NativeAudio. Here's one such post: https://forums.meteor.com/t/low-latency-plugin-working-on-meteor-1-2/11590/6. That post is actually a good example of a poorly supported cordova plugin as well.

The use cases for this are many. But to give an example, if I want to play a file thats physically on my device, so I don't have to go to the web to retrieve it, lets say, for the cordova-plugin-media plugin I need to retrieve the actual local file path. There is almost no documentation on this.

Heres what I found via poking around the file system, and note that this actually changed between meteor 1.0 and meteor 1.2 ( assuming because of the different cordova version).

Lets say I want to get the local cordova file path for a file that you've stored at /public/sounds/bell.wav.

var yourFilePath = 'sounds/bell.wav';

//Meteor 1.0 and under:
var myLocalPath = cordova.file.applicationDirectory + 'www/application/' + yourFilePath;

//Meteor 1.2 and over
var myLocalPath =  cordova.file.applicationDirectory + 'www/application/app/' + yourFilePath;

Why is my app randomly shutting down ( this is mostly for iOS in large apps)

If your not getting exceptions, this is most likely a memory issue. Look into the xcode performance monitor, look for memory leaks and memory warnings. If you have an older device such as an ipad 1, your probably triggering the os to shut down your app. These are really hard problems to solve, especially if your using cordova plugins. I had this problem with cordova-background-location really early on in development, and it turned out there was an array that was never, ever getting cleaned of location data, which was increasing my running app memory to 150+ megs.

from guide.

The initial outline:

Meteor guide: Mobile

Build a really good mobile experience with just a little bit of extra effort.

1. How to set up your development environment for Android and iOS
2. How to enable mobile debugging, logging, testing
3. How to optimize your user experience on mobile to make your app feel smooth and usable
4. How to use native mobile features through Cordova plugins
5. How to add push notifications, intents, and other mobile operating system integrations
6. How to use hot code push effectively to update your app outside of the normal app store review process while maintaining a great user experience

from guide.

I think @martijnwalraven will be a very valuable resource here. Some questions for you, Martijn!

• How do you do debugging, logging, testing on iOS/Android?
• What should people know when they are using cordova plugins? How do you know which ones work, what is the best way to search for them, etc?
• Do we know much about push notifications?
• What changes are coming for hot code push in 1.3? Or is it just more stable?

from guide.

Also I suspect @timbotnik could add some value.

from guide.

@pmwisdom I haven't taken a deep look at this yet, but I'd like to pre-emptively thank you for taking the time to write all of this and help out with the guide!

from guide.

No problem, Glad to help.

from guide.

More Meteor Cookbook articles...

Mobile Apps
Offline Apps

from guide.

@awatson1978 some great tips in there, especially about how to make your app feel more native!

I'm going to try to get more feedback from @martijnwalraven, then write up an outline for this.

from guide.

Topic 1 ('How to set up your development environment for Android and iOS') could either refer to the existing wiki pages, or the other way around. The current instructions need updating for a more recent Android Studio version, and again when we update to the latest Cordova platforms for Meteor 1.3 (that will require Android SDK 23). I'm also looking into incorporating the install-reqs feature from TACO instead of recommending Android Studio.

I'm not sure about the difference between topics 4 and 5. I think 'How to use native mobile features through Cordova plugins' could encompass both.

What I think would be useful here is a way to get people started with at least some of the Cordova core plugins, with features like geolocation, camera, file access, etc. Telerik has a nice overview of core plugins as part of their docs, a table like this could be a good starting point. There is also some Meteor-specific information that would be useful here, such as differences in file access due to our file serving and hot code push plugin (also see @pmwisdom's section on /public). Besides these plugins, we should offer some guidance for common functionality outside of core, like push notifications. And we may want to mention Meteor's mobile packages here (if we decide we can keep them up to date).

Topic 6 ('How to use hot code push effectively to update your app outside of the normal app store review process while maintaining a great user experience') will require some changes for Meteor 1.3 (we'll use meteor.local instead of localhost, it should be more performant/reliable, and require less workarounds to get a good updating UX). There are also some common problems with deployment, where people forget to set ROOT_URL on their server, so we should definitely mention this here.

A missing topic might be how to get your app ready for the app store. This would contain some of the existing information about building, signing and uploading archives, but also more detailed guidance for app icons, launch screens, etc. This may also be the place to mention testing services like TestFlight and HockeyApp.

from guide.

Notes from talking with @martijnwalraven over Hangouts

1. We need to figure out which plugins work
   1. Microsoft doesn't recommend the plugin anymore
   2. http://taco.tools/docs/validated-kits.html
   3. List of known issues is interesting
   4. Telerik: http://docs.telerik.com/platform/appbuilder/creating-your-project/using-plugins/using-core-plugins/using-core-plugins
   5. Perhaps warn people about the state of the plugin ecosystem - you're somewhat on your own, and we can't really debug them for you
2. Debugging/logs
   1. adb log cat on Android, Meteor does it for you
   2. Don't have it on iOS, you can use Xcode
      1. It's possible that running your iOS simulator via Xcode is always a better idea (ask tim)
      2. Almost certainly
3. Cordova plugins and Meteor
   1. Loading them is a bit weird, we should elaborate
4. Separate section for file access?
   1. Accessing files in a bundle vs. files on the file system (not possible in 1.2, Martijn is still working on it)
5. We should throw the installation directions on the guide as well, to move stuff of of the Wiki
6. How to get your app in the app store
   1. The current info is somewhat out of date, and possible incomplete
   2. Sizes of app icons, how to use testing services
   3. Who is going to write this section??
7. Investigate if ground db works well for offline mobile access
8. Maybe reach out directly to more people using mobile in production
   1. Dispatch
   2. Flowkey
   3. Rocket.Chat
9. Plan: Sashko writes an outline, if there are some gaps, then Martijn can fill them in

from guide.

OK, I tried to compile everything into an outline: #81

I'd love to get more feedback about this - it's one of the hardest ones to put together for me.

from guide.

Would like to recommend that the Meteor guide include three additional chapters:
Creating a Meteor Mobile App (issues like choosing an appropriate framework, Cordova, etc).
Building a Meteor Android App (issues like mobile config, getting it to the device, simulator testing, build, code signing, etc).
Building a Meteor iOS App (as above plus XCode-related issues).

One of the principle reasons to use Meteor is cross-platform compatibility. This is also one of the main areas where time is spent. I strongly urge the creation of material on this. I suspect that these chapters will be some of the most widely used in the end. Once someone has long-ago forgotten learning Meteor basics, they still need to stay up to date on the latest tweaks required to get apps to run in mobile environments. This is critical for everyone from first-time-app-builders to senior developers (who in my experience still end up having to do a lot of research as part of getting a new app to publish given how quickly all of the tools change).

Also, I'd like to suggest that sample 'real' mobile apps, with all the required bits and pieces required of an actual production-quality app, be provided.

from guide.

@cdcv did you get a chance to look at the outline at linked at the top of this thread? I believe it includes most or all of the points you mentioned.

from guide.

Great, thanks. I missed the link to the outline at the top. This will be fantastic, and I look forward to it. Thanks to all contributors.

from guide.

@stubailo / @tmeasday i could possibly help with 8.2 in the outline
8. Accessing local files
2. Local files (not possible in Meteor 1.2, we're working on it)

see here for a setup that i use on several apps successfully - meteor/meteor#3799
this package runs the cordova http server - https://atmospherejs.com/natestrauser/cordova-file-server
demo app - https://github.com/nate-strauser/meteor-offline-mobile-files-demo

using this approach local files can be easily used (images, audio, videos, pdf, etc) when the app is online or offline

unless @martijnwalraven is going to alter the meteor cordova behavior to allow access to local files, running a second cordova http server for local files seems a reasonable solution

if you think this is an acceptable approach to promote, i'd be happy to draft up a section about this

from guide.

Let's see what Martijn says, I heard he might be fixing this in 1.3.

from guide.

While creating a Cordova app I realized my users will also be able to access the version on the site which is something I would like to prefend. Could you please add this usecase and possible solutions to the guide?

from guide.

@ericvrp I think this will come as part of the app structure guide, which will have some tips about how to ship separate code to different clients like the mobile app. If I understand correctly, you're asking: how do I make my mobile app totally different from the website?

from guide.

how do I make my mobile app totally different from the website?

Yes - I might be overlooking something obvious and it also perhaps does not belong in this thread. With Meteor.isCordova I could prefend the website from working but still all client side code would be send to the browser. So my question is really how to make it harder for endusers to see my client side codebase. (I know they could get to my code with a jailbroken phone).

from guide.

I'm not sure it's possible to have code that's only shipped to cordova (maybe in the new 1.3 modules system you could with import inside isCordova?).

@martijnwalraven do you know more?

Even if you could, the cordova files are available as well at an HTTP endpoint for hot code reload on mobile, but I'm guessing you'd still prefer this to shipping it to the web browser by default?

from guide.

@tmeasday I was thinking we could recommend a pattern where you have multiple Meteor apps and share code via packages?

from guide.

In many cases the mobile version of the app (for many reasons) is developed as a different Meteor project.

Thus it should point to the main server for DDP connection and to the code server for hot code push.

Something similar to:

meteor run android-device --mobile-server --mobile-hotcodepush my_app_name.meteor.com

from guide.

@ecerroni: The issue with that is that hot code push actually uses the DDP connection. So the default DDP connection should be to the server also serving the code. You can open a separate DDP connection to another server though, and use that to load the data from.

from guide.

Thanks for the reply. I know that and indeed is how I'm doing it now.

I was hoping about something handy in the command line. I'm aware it's kind of a lazy approach though.

from guide.