Meteor: Meteor 1.3 *early beta* (Cordova)

[martijnwalraven]

_1 Upvote_ As you may know, we've started the process towards Meteor 1.3 last month with a beta release of the modules support and related features.

Another area of improvement for Meteor 1.3 is the Cordova integration. Because we don't want to entangle this too much with the modules work we've decided to release these changes as a separate beta for now.

Some of the changes to our Cordova integration in this beta are:

• Dependencies have been upgraded to Cordova 6.0.0, Cordova iOS 4.0.1 and Cordova Android 5.1.0.
• On iOS, we now use WKWebView by default, which should greatly improve JavaScript performance
• The file serving and hot code push plugin has been completely rewritten for reliability and performance:
  -Files are served from localhost instead of meteor.local. Among other things, this means the server is considered a trusted origin and web views will not block secure operations.
  
  
  
  • On iOS, switching to a real embedded web server allows for better caching, streaming, and source map support.
  
  
  • The plugin also allows for local file access on both iOS and Android. You can construct file system URLs manually (http://localhost:<port>/local-filesystem/<path>) or use WebAppLocalServer.localFileSystemUrl() to convert a file:// URL. On iOS, core plugins like cordova-plugin-file and cordova-plugin-camera (using Camera.DestinationType.FILE_URI) will now automatically return these URLs instead of file:// URLs
  
  
  • Downloading updates now uses native file transfer mechanisms (NSURLSession on iOS), which makes it much more reliable.
  
  
  • It only downloads changed files and does not copy files unnecessarily.
  
  
  • It makes sure to always end up with a valid version of all assets, even if downloads take a while or are resumed later.
  
  
  • It contains a safety mechanism that reverts to the last known good version when a faulty version has been downloaded (meaning it contains JavaScript errors that keep it from starting up).
  
  
• It enables support for building Android apps on Windows

You can find out more about the design of the new plugin in the README at https://github.com/meteor/cordova-plugin-meteor-webapp.

Try the release by running meteor update --release 1.3-cordova-beta.5 in your app directory.

_Note that this beta also includes the changes in the 1.3 modules beta, so you may want to refer to https://github.com/meteor/meteor/issues/5788 for more information about those._

Please let us know what works well or what doesn't!

A few notes:

• iOS apps now require iOS 8 or higher, and building for iOS requires Xcode 7.2 to be installed
• Building for Android now requires Android SDK 23 to be installed
• Upgrading to a newer version of Cordova may require you to upgrade your plugin versions. We ensure core plugins use the minimum required version, but you may encounter compiler errors or undesirable behavior with third party plugins. Upgrading to newer versions of these plugins may help if they have been updated to work with recent versions of Cordova.
• When opening the generated project with meteor run ios-device, Xcode will show a dialog asking whether to Convert to Latest Swift Syntax. Make sure to click cancel here, because this conversion will leave the code in an invalid state (this seems to be an Xcode bug).
• Some of the icon and launch screen image sizes have been deprecated, so you may receive warnings about this.

[Exilz]

Great jobs, gratz !
Are you planning on making the Android's hot code push as fine-grained as iOS' ?
If so, do you think it will be available by Meteor 1.3 release ?

Right now, the hot code push system is a huge problem for us, as it comes with many problems, even when we try to disable it. We're about to put two apps in production and we're kinda worried about the state of HCP right now.

[ModrichBadr]

Thanks a lot, I will be trying it today.

[martijnwalraven]

That is definitely the plan. We don't want to delay the release of Meteor 1.3 if I can't get hot code push on Android finished in time however, so if that happens it might not initially have complete feature parity with iOS.

What problems specifically are you worried about on Android?

[ModrichBadr]

@martijnwalraven
I'm having an issue with the app continually refreshing:

[martijnwalraven]

@MoeBadr: When Meteor.startup callbacks don't complete within a set time (currently 10 seconds), the version is considered faulty and it will revert to the last known good version. If there is no last known good version, it will revert to the initially bundled version. What I suspect is happening here is that the initially bundled version itself is faulty (meaning the startup callbacks don't complete in time). It probably should detect that and not try to revert.

Can you try Safari remote debugging to check for JavaScript errors? You may have to enable 'preserve logs' to make sure the reloads don't clear the console so the logs stay visible.

[ModrichBadr]

@martijnwalraven Thanks, I found my issue:

[Error] Refused to load the script 'https://js.stripe.com/v2/' because it violates the following Content Security Policy directive: "script-src 'self' 'unsafe-inline' 'unsafe-eval'".

[Error] Refused to load the script 'https://checkout.stripe.com/checkout.js' because it violates the following Content Security Policy directive: "script-src 'self' 'unsafe-inline' 'unsafe-eval'".

[martijnwalraven]

Ah, it seems the Content-Security-Policy we put in by default doesn't allow external scripts. This is definitely not desirable, so I'll change it. Thanks for the report!

[ModrichBadr]

@martijnwalraven please have look into this:

'[Error] XMLHttpRequest cannot load http://localhost:3000/cfs/servertime. Origin http://localhost:12981 is not allowed by Access-Control-Allow-Origin.'

My mobile-config contains App.accessRule('*'), also tried App.accessRule('http://*'); App.accessRule('https://*');

[Exilz]

"What problems specifically are you worried about on Android?"

@martijnwalraven Well, the thing is that we have noticed that after an update through the Play Store, some content delivered through Hot Code Push persisted...
For instance, I exported an apk which had a template with "Version 0.0.1" written in it. No vars, plain string.

Later on, I exported another apk with "Version 0.0.2". I uploaded it on the Play Store (with the beta testing service you can send to your clients, you know).
After the automatic update, most of the app was ok, but this template, for instance, was still showing "Version 0.0.1".

This worried us A LOT.

And the thing is that, I'm pretty sure I disabled the hot code push... like so:

const DISABLE_HCP = true,
      DEBUG = false,
      AUTOUPDATE_HASH = '002';

if (DISABLE_HCP) {
    // When shit hits the fan (or in production),
    // disable hot code push
    Meteor._reload.onMigrate(function() {
        return [false];
    });

    __meteor_runtime_config__.autoupdateVersion = AUTOUPDATE_HASH;
    __meteor_runtime_config__.autoupdateVersionCordova = AUTOUPDATE_HASH;
    __meteor_runtime_config__.autoupdateVersionRefreshable = AUTOUPDATE_HASH;
}

The autoupdate hash is the same that I provided on my MUPX deployment, like so

  "env": {
      "MONGO_URL": "mongodb://xxx:1337/xxx",
      "DDP_DEFAULT_CONNECTION_URL": "http://xxx:3143",
      "AUTOUPDATE_VERSION": "002",
      "AUTOUPDATE_VERSION_CORDOVA": "002",
      "AUTOUDPATE_VERSION_REFRESHABLE": "002"
  }

Without overriding these environment vars, even with onMigrate returning false, it seemed like the hot code push was done anyway...

We're kinda sweating right now to be honest. Maybe we misunderstood something, I sure hope so.
Thanks for your time !

[martijnwalraven]

@MoeBadr: Is this a new error with Meteor 1.3? I would have expected it to also have been a problem previously. App.accessRule won't help you here, because that only affects the access rules the client has control over. CORS requires the server to add an appropriate header. See here for an example.

[martijnwalraven]

@Exilz: There is a known issue with the old hot code push mechanism where hot code pushed versions always take precedence over bundled versions. So even if you then upload a new version to the Play Store / App Store, the app will continue to use the previously downloaded version and not the new bundled version. Normally, it should then immediately hot code push the new version (which is actually the same as the bundled one) and use that from then on. But with hot code push disabled, that never happens.

This has been fixed with the plugin rewrite for Meteor 1.3, at least on iOS. On Android, there is currently no hot code push at all, so also no danger of this occurring. But the rewrite of the Android plugin will have the same behavior as the iOS version and so also won't have this issue.

(Meteor._reload.onMigrate doesn't actually disable hot code push, but only affects when a reload happens after a new version has been hot code pushed. So fixing the autoupdate versions is indeed the only way to truly disable it.)

[Exilz]

@martijnwalraven thanks for your answer. I'll try to build with the latest beta you provided and check if that still happens.

[ModrichBadr]

@martijnwalraven you right, thanks for the link :)

[nerdmed]

@martijnwalraven thanks a lot for this update - its a major improvement for all working with meteor and cordova!
I have just one thing: During the last month in production we've noticed that its not always the best idea to have the first start of the application after App-Store download with an old client side bundle. We ran into some issues where server and client did not like each other because during the apple review process you will deploy a new version to your production servers but app store downloads will be stuck an old client. So everyone downloading your app during the submit could run into some ugly issues and you always have to take care of that or sometimes you just want to fix something in the registration or onboarding that will happen on the first start of the application.

With the new improvements you can assume that on the first start the difference between the client side bundle that is downloaded from the App Store and the one on the server is not that big. Therefore it would be really great to be able to force the client to continue to download and hot code reload on the first start. Maybe even he leaves the first splash screen.
I think this kind of behavior should be implemented inside a meteor package but what we would need to create such a package is more information about the progress of the autoupdate. Since its now mostly native code it would be great to get some more functions to check for some things like:
is there an bundle download currently running and how far is my progress. Is something like that planed or maybe already in place?

[martijnwalraven]

Good to hear! Is everything else working with your app? Have you encountered any issues?

There has been some discussion about getting more information about the status of downloads at
https://github.com/meteor/meteor/issues/4876. Let's continue the discussion there. The plan is definitely to get something in that would help with this use case.

[Chun-Yang]

Hey @martijnwalraven, thanks for this awesome update. I get an error like this when trying to run on an iphone device.
/Users/trent/Work/hoopla/.meteor/local/cordova-build/platforms/ios/hoopla/Plugins/com.phonegap.plugins.PushPlugin/PushPlugin.m:274:23: No visible @interface for 'UIView' declares the selector 'stringByEvaluatingJavaScriptFromString:'

- (void)notificationReceived {
    NSLog(@"Notification received");

    if (notificationMessage && self.callback)
    {
        NSMutableString *jsonStr = [NSMutableString stringWithString:@"{"];

        [self parseDictionary:notificationMessage intoJSON:jsonStr];

        if (isInline)
        {
            [jsonStr appendFormat:@"foreground:\"%d\"", 1];
            isInline = NO;
        }
        else
            [jsonStr appendFormat:@"foreground:\"%d\"", 0];

        [jsonStr appendString:@"}"];

        NSLog(@"Msg: %@", jsonStr);

        NSString * jsCallBack = [NSString stringWithFormat:@"%@(%@);", self.callback, jsonStr];
        [self.webView stringByEvaluatingJavaScriptFromString:jsCallBack]; /* <------- THIS LINE */

        self.notificationMessage = nil;
    }
}

[Chun-Yang]

This problem is caused by https://github.com/raix/push

[martijnwalraven]

Release 1.3-cordova-beta.2 is now available. This fixes a bug with Content-Security-Policy that disallowed loading of external scripts, and adds local file system access on iOS.

[ModrichBadr]

@martijnwalraven :+1: , Thanks.

Edit:
upon running the app iOS (works fine for Android), I got this error:

Failed to load resource: The resource could not be loaded because the App Transport Security policy requires the use of a secure connection.

I resolved (temp fix) this error by adding (info.plist):

Allow Arbitrary Loads: true

issue: http://stackoverflow.com/questions/32631184/the-resource-could-not-be-loaded-because-the-app-transport-security-policy-requi
`

[nerdmed]

@martijnwalraven thanks for the hint.
After replacing all old cordova plugins the build succeeds. Because of some bigger workarounds in the old version it will take us a little more to get the app fully running. The only thing i have noticed on the server running with mobile settings. Is the following error:

Error serving static file RangeNotSatisfiableError: Range Not Satisfiable

[martijnwalraven]

@nerdmed: Thanks for the report. That sounds like something worth investigating. Could you open a separate issue for that and see if you can find a minimal reproduction?

[martijnwalraven]

@MoeBadr: Where are you loading the resources that result in the App Transport Security error from? Domains added through App.accessRule (as well as the server address) should automatically configure the right ATS settings. So it shouldn't be necessary to set Allow Arbitrary Loads.

[guidouil]

Hello, I have an issue with image made of base64 encoded data in the src attribute in Android. It does work in iOS. Can you give me a hand ? all the rest works perfect in my app.

[martijnwalraven]

@guidouil: Good catch! It turns out wildcard content sources do not match data: (or blob:) schemes, so the default CSP meta tag we include for Cordova blocks those URLs. Fixed in https://github.com/meteor/meteor/commit/46c9201a7f625e30040dfa0a5246d3d79a129f6b (should be in the next beta).

Note that depending on your use case however, it may no longer be necessary to use base64 data for images. The new plugin supports local file access (in the current beta only for iOS, Android will be in the next one). That allows you to use file URLs instead of base64 data, which should be more performant.

[guidouil]

My use case is cropping an image before upload. I don't want to store this temporary image so base64 was a good local compromise before uploading to gridfs

[ModrichBadr]

@martijnwalraven I'm deploying to meteor.com, which the --mobile-server point to.

I can see Exception Domains in info.plist contains the --mobile-server url & localhost but still throws Failed to load resource: The resource could not be loaded because the App Transport Security policy requires the use of a secure connection. for the --mobile-server url.

[martijnwalraven]

@MoeBadr: Thanks, I've been able to reproduce this now. It seems the exception domain in ATS should not include a path (like the wildcard one we currently include: /*). These are supported as part of the <allow> tags in config.xml however, which Cordova translates into ATS directives. For now, I'm just going to remove the wildcard path from the domains we add automatically, but I should probably open an issue with Cordova to get this fixed there.

[martijnwalraven]

Currently looking into another issue where a bundle downloaded from *.meteor.com does not include an appId.

[Obiwarn]

I have tears in my eyes.

This update fixes so many issues we had with mobile development.

Thank you!

[martijnwalraven]

Release 1.3-cordova-beta.3 is now available. This release adds local file access for Android, where we now serve apps from file://app/ instead of localhost.

It also adds experimental support for Android development on Windows, thanks to @sedouard's pull request. If you're a Windows user, please give this release a try and let us know what is or isn't working for you.

[Exilz]

@martijnwalraven What can we except in terms of starting times on Android ?
I've noticed a GREAT improvement on iOS. My app that's quite heavy takes only 3/4 seconds to start up on an iPhone 5. It used to be much more.

On my fastest Android, it's usually around 12 seconds. On a Galaxy S3, it takes up to 22 seconds...
Is that related to some sort of assets verification and the native code that you wrote for iOS ?

[Tibo46]

I can confirm Android deployment on windows is working as expected!

[martijnwalraven]

@Exilz: Good to hear startup has improved on iOS! Do you have any idea what the startup time used to be on that device?

I suspect the difference mostly has to do with switching to using a local web server on iOS, which also allows for better control over caching. Unfortunately, the mechanism (shouldInterceptRequest) used on Android doesn't allow that level of control (at least for API < 21).

Your numbers seem really high though, so I'm interested in finding out what causes that. Do you use a lot of plugins? Do you have a lot of files or big assets? Is there a difference between running in development and running in production (running with --production, which minifies the JavaScript files and joins them)?

[Exilz]

@martijnwalraven Yeah I do use a lot of plugins, here's the list

com.danielcwilson.plugins.googleanalytics
com.telerik.plugins.nativepagetransitions
cordova-plugin-customurlschemecordova-plugin-dialogs
cordova-plugin-x-socialsharing
org.apache.cordova.geolocation
cordova-plugin-inappbrowser
org.apache.cordova.network-information
org.apache.cordova.splashscreen
org.pbernasconi.progressindicator
uk.co.workingedge.phonegap.plugin.LaunchNavigator

I don't quite remember for sure the previous average time on iOS. I guess it was around 8 sec.

Regarding my quantity of assets, do you mean what's inside the public folder ? If so, it weights 2.3Mb
It contains 50 files, plus 36 more if you can splashscreens.
Is that too much ? Should I put my images/fonts elsewhere ?

I'm also using https://github.com/frozeman/meteor-persistent-minimongo2 which syncs minimongo with localForage. It's pretty ressource-heavy, I'm not sure how it impacts the initial loading time.
EDIT : After testing, it doesn't change the start up time, since the sync is done after the splashscreen is released anyway.

Once the APK is build with meteor build and sign, it doesn't start much faster.

[martijnwalraven]

@Exilz: Thanks for the details. I won't get to this until next week, but I would like to take a closer lookat what is causing these slow startup times for Android.

I don't expect this to change startup, but your splash screens and icons shouldn't be inside your public folder, because these will only be used during the build process.

[Exilz]

@martijnwalraven Thanks for looking into this. I'll move splash screens and icons in another folder then.

[sedouard]

@Tibo46 good to hear! :beers:

[mscherer82]

@Exilz I had to override the splashScreenDelay in my mobile-config.js to decrease startup time. Seems that the default value is set to 10secs.

[Exilz]

@mscherer82 Yup, I did that too.
It looks like the version of apache-cordova-splashscreen I was using was causing delay on startup.
I updated it to its latest version, with the fade and spinner option on Android. It's much faster now.

I also removed some weight in my assets and made some optimizations regarding initialization. It now starts much faster.

[martijnwalraven]

@Exilz: Good to hear you managed to improve your startup time! Could you maybe share some numbers, and explain what you changed? This sounds like useful information to put in the mobile article in the meteor guide.

[fungilation]

Cordova 6.0.0 just got released. Of particular interest I think:

• Removed support for our old Cordova Plugins Registry. Now plugins can only be installed via npm, git URL or local paths.

[jamalx31]

$meteor.loginWithPassword doesn't work with beta.3 on android
sometimes I got this error:
W/chromium(22634): [WARNING:keycode_converter.cc(100)] empty code string

[jhatchr]

Thanks @martijnwalraven for working on such a great and essential update for iOS! I’m seeing up to 75% less memory used by the app which seems to have eliminated reproducible memory crashes. However, I’m finding some build issues that are preventing us from moving forward…

Using:

Meteor 1.3-cordova-beta.3
cordova:cordova-plugin-dialogs              1.2.0
cordova:cordova-plugin-inappbrowser         1.2.0
cordova:cordova-plugin-network-information  1.2.0
cordova:cordova-plugin-splashscreen         3.1.0

meteor build ~/path --server=https://domain.com:443

In Simulators (Xcode 7.2, iOS 9.2) everything works great and connects properly.

When running the build on physical devices (iPad iOS 9.2 & iPhone 6p 8.3) the iPad works as expected, but the iPhone just hangs at the splash screen and/or transitions to a white screen.

When running on the iPhone 8.3, I noticed this in the Xcode logs:

2016-02-01 09:40:14.018 MemLife[15228:2328190] Using WKWebView
2016-02-01 09:40:14.130 MemLife[15228:2328190] Using UIWebView

iOS 8.3 seems to revert back to UIWebView, which I suspect is causing the iPhone issue (the UIWebView revert doesn’t happen when running on the iPad on 9.2)

Also, when building an archive (using Generic iOS) and ad-hoc installing the .ipa on the same devices - the app doesn’t work at all on either device. The splash screen just displays for a second and then the app closes.

[jamielob]

Hi @martijnwalraven - Been testing out 1.3 with our production app that's in the app store and everything is looking great so far. I just wanted to let you know that a problem we were having in 1.2 is still present in 1.3. It happens when we add or remove a cordova plugin, and then try to re-run the app using the ios-device command. It results in an error starting with:

Failed to install 'cordova-plugin-blah-blah':TypeError: Cannot read property 'buffer' of undefined at walk_obj...

To fix the error all we have to do is go in to the project's .meteor/local directory and delete the cordova-build folder and it the runs fine.

Anyone else having this issue?

[martijnwalraven]

@jamielob: This sounds like https://github.com/meteor/meteor/issues/5171, which turned out to be caused by an existing Cordova issue related to plist processing during plugin install/uninstall. It seems this still hasn't been fixed downstream.

[aesmon]

1.3 works great, I am happy that hot code push does not break my iOS app anymore which makes it a breeze to test. However, sometimes even though the app reloads successfully after a hot code push the app becomes unresponsive, and I have to close it and launch again.

@jamielob Haven't experienced any issues when adding/removing cordova plugins

[jamielob]

@martijnwalraven - thanks, looks like it's probably related to that. Some people are reporting that it's fixed in 5.4.1 but I haven't seen that. In the meantime I've just set up an alias for resetcordova.

alias resetcordova='rm -rf .meteor/local/cordova-build'

[jamielob]

@martijnwalraven - 2 questions.

1) When I update "server only" code it's refreshing the mobile client (iOS). Is that intended/expected?

2) It's also updating the mobile client as soon as it is saved. Are there different behaviors in development and production? e.g. updates immediately in development and waits for the app to closed in production?

[nerdmed]

@martijnwalraven we are still working on our 1.3 port :cry: - a workmate ran into an issue with a Cordova plugin and traced the reason to the name attribute inside the plugin.xml - there error seems to be new with 1.3 - maybe this is interesting for your or for other people porting #6156

[jamielob]

@jhatchr - I am also seeing a revert to UIWebView on iOS 8.3

2016-02-05 20:05:55.980 meteor-project[5524:922955] Using WKWebView
2016-02-05 20:05:56.055 meteor-project[5524:922955] Using UIWebView

I'm also getting the splash screen hang. The line below added to mobile-config.js hides the splash screen, but I just end up with a blank white screen with none of the app loaded.
App.setPreference('AutoHideSplashScreen' ,'true’);

@martijnwalraven - To reproduce simply run meteor run ios-device on a device running 8.3. Do you want us to open up separate issues for these bugs anywhere rather than putting it all in this one thread?

[jamielob]

@martijnwalraven @jhatchr - I just tested on 8.3 with the beta.2 release and it works fine (no splash screen hang, no need for autohide setting, and uses wkwebview).

[martijnwalraven]

@jamielob: Thanks for the report! I've been able to track the problem down and this will be fixed in the next beta.

[jamielob]

Thanks @martijnwalraven! Did you see my questions from 2 days ago by any chance?

[martijnwalraven]

@jamielob:

1. No, server only changes should not refresh the client. I just checked, and if I make a change to a file in the server directory a client refresh doesn't happen. Maybe you are referring to changing code within a Meteor.isServer() block? There is currently no way for Meteor to detect that a change to a file that is shared between client and server only affects the server.
2. There is no difference in behavior between development and production. By default, the app reloads with the changes as soon as they are done downloading. You can use the mdg:reload-on-resume package to wait until the app goes into the background.

[dagatsoin]

Hi @martijnwalraven is the last beta is still developed appart from the Modules branch?

[martijnwalraven]

Yes, but I'm rebasing on top of the modules branch for the next beta.

[dagatsoin]

ok cool, my project is ready to test :)

[jhatchr]

@martijnwalraven - have you had any issues getting exported .ipa files to work on devices?

I'm unable to get an .ipa file (Archive > Export to ad-hoc) to work (beta.3 - Xcode 7.2 - iOS 9). As above, it just shows the splash for a second and crashes.

meteor run and meteor build work as expected when running it through Xcode to a device or a simulator (works in iOS 9+, reverts to UIWebView in iOS 8+). Archive > Export .ipa > iOS 9 device produces the same result (crashes immediately after opening).

@jamielob are you able to get beta.3 to a working .ipa? Anyone else experiencing this?

iPad crash report below. I'm cancelling out of the Swift prompt whenever I see it and tried setting the Xcode Build Setting "Embedded Content Contains Swift Code" to YES mentioned here:

Incident Identifier: 2E452C24-99E8-4091-A540-4D44D31B9ADC
CrashReporter Key:   d1254f90d32881720e33c4ec0ddd34c045092b08
Hardware Model:      iPad2,1
Process:             ProjectName [728]
Path:                /private/var/mobile/Containers/Bundle/Application/E1CD36E6-AAD5-4367-95D1-1FB39CB83E41/ProjectName.app/ProjectName
Identifier:          com.id1cr5gdd1cxnr3574toix
Version:             0.9.0 (0.9.0)
Code Type:           ARM (Native)
Parent Process:      launchd [1]

Date/Time:           2016-02-09 17:12:26.26 -0500
Launch Time:         2016-02-09 17:12:26.26 -0500
OS Version:          iOS 9.2.1 (13D15)
Report Version:      104

Exception Type:  EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000001, 0x00000000e7ffdefe
Triggered by Thread:  0

Filtered syslog:
None found

Dyld Error Message:
Dyld Message: Library not loaded: @rpath/libswiftCore.dylib
  Referenced from: /var/mobile/Containers/Bundle/Application/E1CD36E6-AAD5-4367-95D1-1FB39CB83E41/ProjectName.app/ProjectName
  Reason: image not found
  Dyld Version: 370.6

Binary Images:
0x3a000 - 0xc1fff ProjectName armv7  <f0fb5a5b2a953cf297d6a50d9f70d805> /var/mobile/Containers/Bundle/Application/E1CD36E6-AAD5-4367-95D1-1FB39CB83E41/ProjectName.app/ProjectName
0x1fec3000 - 0x1feeafff dyld armv7  <d26f8044782f3034857415d6e93e7b8e> /usr/lib/dyld

Error Formulating Crash Report:
Failed while requesting activity/breadcrumb diagnostic

[jamielob]

@jhatchr - I just tried archiving and exporting to ad hoc and had no problems. I am however using the beta.2 as opposed to beta.3. Can you try using --release 1.3-cordova-beta.2 and see if your results are the same? Be sure to delete your cordova-build directory first.

[wojtkowiak]

@jhatchr

Go to project build settings and add @executable_path/Frameworks to Runpath Search Paths

This one fixed almost the same problem for me. I had to set it for both Debug and Release.
However I am including a bunch of plugins so my issue could have been caused by one of them.

[jhatchr]

@wojtkowiak Thanks that worked! @executable_path/Frameworks was only set for Debug in Runpath Search Paths.

@jamielob Thanks - I tested and beta.2 built for iOS 8.3 properly (simulator), but the problem above was the same. Updating @executable_path/Frameworks in beta.2 also created a working ad hoc .ipa

[Exilz]

Hey @martijnwalraven,
regarding start up time I forgot to answer.
Actually, the problem was very specific to our application, so I don't think I could make a "genreal statement" about improving this delay, sorry :/

[JohnBernardsson]

Android deployment on Windows is working pretty good for me aswell! Great work @sedouard! :smiley:

I just got one little issue so far: if your project is within a folder with a white space in its name, the "meteor run" command would report an error, something like "Unknown command".

Now I am also facing a different problem, that has to do with CollectionFS. I'll report the problem there also, but just pointing it out here in case someone has any clue about it. This is the error I am receiving, once the app is already deployed, and loads in the device:

 (android:file://app/packages/cfs_access-point.js:285) failed [404] <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>404 Not Found</title> </head><body> <h1>Not Found</h1> <p>The requested URL /cfs/servertime was not found on this server.</p> </body></html>

I tried adding a mobile-config.js file, with the line:

App.accessRule("blob:*");

Just in case it had to do with a known bug, but it didn't change anything.

Thanks for the hard work!

[martijnwalraven]

Release 1.3-cordova-beta.4 is now available. This includes hot code push support for Android!

Other changes include:

• This beta now also includes the changes in the 1.3 modules beta, so you may want to refer to #5788 for more information about those.
• Cordova has been upgraded to 6.0.0 and Cordova Android to 5.1.0. I've also updated the pinned plugins to the latest versions.
• I've reverted the change to file://app/ on Android made in the previous beta, because of issues with file:// URLs that do not seem fixable. So we now serve files from http://localhost:<port> on both iOS and Android. I hope to reenable local file access on Android again in a later beta.

[ModrichBadr]

@martijnwalraven Amazing!!!!, Thank you :)

[markshust]

Are the changes from #5788 for beta8 of that project?
On Thu, Feb 11, 2016 at 9:03 AM Mohamed Badr [email protected]
wrote:

@martijnwalraven https://github.com/martijnwalraven Amazing!!!!, Thank
you :)

—
Reply to this email directly or view it on GitHub
https://github.com/meteor/meteor/issues/6050#issuecomment-182876843.

[dagatsoin]

You made my day with the rebase!!🤗

Le 11 févr. 2016 à 15:04, Mohamed Badr [email protected] a écrit :

@martijnwalraven Amazing!!!!, Thank you :)

—
Reply to this email directly or view it on GitHub.

[martijnwalraven]

@markoshust: Yes, plus a merge with devel and one more commit, see branch release-1.3.

[m-gv]

@martijnwalraven Trying to launch application under windows in 1.3-cordova-beta.4 I get the following stackrace with verbose output

C:\prj>meteor run android
[[[[[ C:\prj ]]]]]

=> Started proxy.
=> Started MongoDB.
=> Started your app.

=> App running at: http://localhost:3000/
   Type Control-C twice to stop.

=> Errors executing Cordova commands:

   While running Cordova app for platform Android with options --emulator:
   Error: Command failed:
   C:\prj\.meteor\local\cordova-build\platforms\android\cordova\run --emulator
   --emulator
   FAILURE: Build failed with an exception.

   * What went wrong:
   Unable to start the daemon process.
   This problem might be caused by incorrect configuration of the daemon.
   For example, an unrecognized jvm option is used.
   Please refer to the user guide chapter on the daemon at
   http://gradle.org/docs/2.2.1/userguide/gradle_daemon.html
   Please read the following process output to find out more:
   -----------------------
   Error occurred during initialization of VM
   Could not reserve enough space for object heap
   Error: Could not create the Java Virtual Machine.
   Error: A fatal exception has occurred. Program will exit.


   * Try:
   Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get
   more log output.
   Error code 1 for command: cmd with args:
   /s,/c,"C:\prj\.meteor\local\cordova-build\platforms\android\gradlew
   cdvBuildDebug -b
   C:\prj\.meteor\local\cordova-build\platforms\android\build.gradle
   -PcdvBuildArch=x86 -Dorg.gradle.daemon=true -Pandroid.useDeprecatedNdk=true" undefined
   at ChildProcess.exitCallback (C:\tools\utils\processes.js:151:23)
   at ChildProcess.emit (events.js:98:17)
   at Process.ChildProcess._handle.onexit (child_process.js:820:12)

ExitWithCode:1

C:\prj>

Any idea what I can do about this? (increasing object heap size in some way maybe?)

[dagatsoin]

Using last modules beta and update to cordova beta 4.

I am not able to start my app with meteor run ios:

TypeError: Can't call method on  undefined
    at TypeError (<anonymous>)
    at module.exports (/Users/vikti/.meteor/packages/meteor-tool/.1.1.13-modules.8.1jogvta++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/meteor-ecmascript-runtime/node_modules/core-js/modules/$.defined.js:3:28)
    at module.exports (/Users/vikti/.meteor/packages/meteor-tool/.1.1.13-modules.8.1jogvta++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/meteor-ecmascript-runtime/node_modules/core-js/modules/$.to-object.js:4:17)
    at from (/Users/vikti/.meteor/packages/meteor-tool/.1.1.13-modules.8.1jogvta++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/meteor-ecmascript-runtime/node_modules/core-js/modules/es6.array.from.js:12:19)
    at exports.default (/Users/vikti/.meteor/packages/meteor-tool/.1.1.13-modules.8.1jogvta++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/babel-runtime/helpers/toConsumableArray.js:19:31)
    at CordovaProject.run$ (/tools/cordova/project.js:207:17)
    at tryCatch (/Users/vikti/.meteor/packages/meteor-tool/.1.1.13-modules.8.1jogvta++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/babel-runtime/regenerator/runtime.js:72:40)
    at GeneratorFunctionPrototype.invoke [as _invoke] (/Users/vikti/.meteor/packages/meteor-tool/.1.1.13-modules.8.1jogvta++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/babel-runtime/regenerator/runtime.js:334:22)
    at GeneratorFunctionPrototype.prototype.(anonymous function) [as next] (/Users/vikti/.meteor/packages/meteor-tool/.1.1.13-modules.8.1jogvta++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/babel-runtime/regenerator/runtime.js:105:21)
    at tryCatch (/Users/vikti/.meteor/packages/meteor-tool/.1.1.13-modules.8.1jogvta++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/babel-runtime/regenerator/runtime.js:72:40)
    at invoke (/Users/vikti/.meteor/packages/meteor-tool/.1.1.13-modules.8.1jogvta++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/babel-runtime/regenerator/runtime.js:146:20)
    at /Users/vikti/.meteor/packages/meteor-tool/.1.1.13-modules.8.1jogvta++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/babel-runtime/regenerator/runtime.js:191:11
    at new Promise (/Users/vikti/.meteor/packages/meteor-tool/.1.1.13-modules.8.1jogvta++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/core-js/library/modules/es6.promise.js:197:7)
    at callInvokeWithMethodAndArg (/Users/vikti/.meteor/packages/meteor-tool/.1.1.13-modules.8.1jogvta++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/babel-runtime/regenerator/runtime.js:190:16)
    at AsyncIterator.enqueue (/Users/vikti/.meteor/packages/meteor-tool/.1.1.13-modules.8.1jogvta++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/babel-runtime/regenerator/runtime.js:211:37)
    at AsyncIterator.prototype.(anonymous function) [as next] (/Users/vikti/.meteor/packages/meteor-tool/.1.1.13-modules.8.1jogvta++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/babel-runtime/regenerator/runtime.js:105:21)
    at Object.runtime.async (/Users/vikti/.meteor/packages/meteor-tool/.1.1.13-modules.8.1jogvta++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/babel-runtime/regenerator/runtime.js:228:12)
    at /Users/vikti/.meteor/packages/meteor-tool/.1.1.13-modules.8.1jogvta++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/isopackets/cordova-support/npm/promise/node_modules/meteor-promise/fiber_pool.js:33:40

Here is a repo: https://github.com/dagatsoin/meteor-1.3cordova.beta4-bug00

$ npm install
$ meteor run ios

[martijnwalraven]

@dagatsoin: That error is due to a problem with the modules work that has been fixed in https://github.com/meteor/meteor/commit/bd144c4cc6d709091f1ea7793a6da9437a6317e2. I plan to push a new beta with this included (and some other changes) tomorrow.

In the meantime, meteor add modules may help you work around this.

[jamielob]

@martijnwalraven - I'm getting an error on android-device with the latest build that I wasn't getting before.

Unfortunately, APPNAME has stopped

is appearing on the device. It looks like this is related to the cordova-plugin-facebook4 plugin, but wasn't happening on earlier builds or 1.2.1.

[martijnwalraven]

@jamielob: Hmmm, this may have to do with the upgrade to Cordova 6.0.0 and Cordova Android 5.1.0. What makes you think it is related to the cordova-plugin-facebook4 plugin? When does the app stop? Do you see any error messages?

[jamielob]

@martijnwalraven: I thought it was that based on process of elimination, but now it looks like it may actually be the Meteor package that uses it. I'll let you know what I find.

[jamielob]

@martijnwalraven: Ok, I think it's related to any Meteor plugin that uses cordova-plugin-inappbrowser.

On beta.4 I'm getting the following warning:

WARNING: Attempting to install plugin [email protected], but it should have a minimum version of 1.2.1 to ensure compatibility with the current platform versions. Installing the minimum version for convenience, but you should adjust your dependencies.

Doesn't appear with beta.3 or beta.2. To reproduce just add mrt:accounts-facebook-cordova and run on an Android device.

[Exilz]

@jamielob I don't know where the repo of this package is located, but it simply seems that its cordova Dependencies in package.json are simply outdated. It's probably due to the new Cordova's version of beta4.

[martijnwalraven]

Release 1.3-cordova-beta.5 is now available. This release includes recent fixes made on the modules branch, reenables local file access on Android, and updates pinned versions of some core plugins.

[martijnwalraven]

@jamielob: Not sure if this helps, but cordova-plugin-inappbrowser has just been updated to 1.3.0 (I've also updated the pinned version in 1.3-cordova-beta.5).

[martijnwalraven]

@dagatsoin: 1.3-cordova-beta.5 includes a fix for your issue.

[jamielob]

@martijnwalraven @Exilz: beta.5 removes the inappbrowser warning but I'm still getting Unfortunately, APPNAME has stopped on the android devices.

[jamielob]

@martijnwalraven @Exilz: I think it's a problem specific to accounts-oauth and Android 4.4.

I've put created a repo showing the problem, but it's simply a new install of meteor with the accounts-oauth package added.

• Tested on a Samsung S3 running 4.4.2 = Unfortunately, APPNAME has stopped
• Tested on a Moto G running 5.1 = No problem

If I change the package to [email protected] (the current version) both start fine.

[martijnwalraven]

@jamielob: Hmmm, accounts-oauth depends on oauth, which depends on cordova-plugin-inappbrowser. So that would still suggest it is an issue with that plugin. I looked at the Cordova JIRA issue tracker but haven't been able to find anything yet.

[jamielob]

@martijnwalraven: I've tested with just the cordova-plugin-inappbrowser both version 1.0.1 and 1.3.0 and they both load fine on the S3 running 4.4.2. If I just add the oath package thought then it gets the same error.

[martijnwalraven]

@jamielob: Is there any way you can get more debug output from the device encountering the issue? I have no way of reproducing this because I don't have a device running Android 4.4 (and the issue could be even more specific).

[jamielob]

@martijnwalraven Here's the logcat dump from just after it shows the error: http://pastebin.com/raw/8Svi1CE1
Not sure if that's helpful or not.

[martijnwalraven]

@jamielob: Nothing jumps out to me, but do I understand correctly this is logcat output after the app has already stopped? Any way to run logcat during app startup?

A stab in the dark, but do you also get the error when using Crosswalk (meteor add crosswalk)?

[jamielob]

@martijnwalraven : You're right, I wasn't running the logcat long enough. Here's the dump: http://pastebin.com/raw/Rqbfb4N6

I think this is the error relating:

D/AndroidRuntime( 6451): Shutting down VM
W/dalvikvm( 6451): threadid=1: thread exiting with uncaught exception (group=0x41dd2da0)
E/AndroidRuntime( 6451): FATAL EXCEPTION: main
E/AndroidRuntime( 6451): Process: com.id1t1w90j6eq7ofcd2z1t, PID: 6451
E/AndroidRuntime( 6451): java.lang.NullPointerException
E/AndroidRuntime( 6451):    at com.meteor.webapp.WebApp.onReset(WebApp.java:235)
E/AndroidRuntime( 6451):    at org.apache.cordova.PluginManager.onReset(PluginManager.java:465)
E/AndroidRuntime( 6451):    at org.apache.cordova.CordovaWebViewImpl$EngineClient.onPageStarted(CordovaWebViewImpl.java:501)
E/AndroidRuntime( 6451):    at org.apache.cordova.engine.SystemWebViewClient.onPageStarted(SystemWebViewClient.java:145)
E/AndroidRuntime( 6451):    at com.android.webview.chromium.WebViewContentsClientAdapter.onPageStarted(WebViewContentsClientAdapter.java:438)
E/AndroidRuntime( 6451):    at com.android.org.chromium.android_webview.AwContentsClientCallbackHelper$1.handleMessage(AwContentsClientCallbackHelper.java:100)
E/AndroidRuntime( 6451):    at android.os.Handler.dispatchMessage(Handler.java:102)
E/AndroidRuntime( 6451):    at android.os.Looper.loop(Looper.java:146)
E/AndroidRuntime( 6451):    at android.app.ActivityThread.main(ActivityThread.java:5487)
E/AndroidRuntime( 6451):    at java.lang.reflect.Method.invokeNative(Native Method)
E/AndroidRuntime( 6451):    at java.lang.reflect.Method.invoke(Method.java:515)
E/AndroidRuntime( 6451):    at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1283)
E/AndroidRuntime( 6451):    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1099)
E/AndroidRuntime( 6451):    at dalvik.system.NativeStart.main(Native Method)
W/ActivityManager(  783):   Force finishing activity com.id1t1w90j6eq7ofcd2z1t/.MainActivity
E/qdmemalloc(  177): heap_msk=3000000 flags=1

[jamielob]

@martijnwalraven : Same result with crosswalk installed. The NullPointerException from the logcat is there on both occasions.

[martijnwalraven]

@jamielob: Thanks, that explains it! It doesn't seem to have anything to do with the Android version directly, but it is a timing issue that means a variable may not be initialized when a log call tries to print it. I'll look into it tomorrow and push a new beta.

[jamielob]

@martijnwalraven Thank you! Glad to have figured out how to debug this properly going forward.

[guidouil]

On my side the image upload to cfs does not work anymore (the data:b64 is fix though) the server does not receive the uploaded file but the image object is created in database. Maybe it's related to WARNING: Attempting to install plugin [email protected], but it should have a minimum version of 2.1.0 to ensure compatibility with the current platform versions. Installing the minimum version for convenience, but you should adjust your dependencies.
And I also get a message regarding the geolocation but I did not test it yet.
WARNING: Attempting to install plugin [email protected], but it should have a minimum version of 2.1.0 to ensure compatibility with the current platform versions. Installing the minimum version for convenience, but you should adjust your dependencies.
Thanks for the brain time Sir :smiley:

[markshust]

@guidouil I received the same -- the versions of cordova plugins you are using are outdated. you can change .meteor/cordova-plugins to the new versions to prevent this message.

[guidouil]

No it come from mdg:camera and mdg:geolocation. I only have [email protected] in my cordova plugins and it does work fine

[martijnwalraven]

@guidouil: The message is just a warning and the plugins will still install at the right version. Thanks for reminding me, we indeed need to update the dependencies in mdg:camera and mdg:geolocation.

Where does the image come from and how are you uploading it? Did it work in earlier betas?

[guidouil]

@martijnwalraven yup it was working in beta.3, the image come from a canvas I convert to base64 and insert into cfs collection / file storage. Usually it get uploaded and I see the file, but now I only have a basic file object giving me file name and size, but no related file and no status uploading or uploaded.

[martijnwalraven]

Is this on iOS or Android (or both)? Have you tried remote debugging through Safari/Chrome? Any error messages?

[guidouil]

It's on both, I get this error message in safari remote debug

[Error] Failed to load resource: Origin http://localhost:12168 is not allowed by Access-Control-Allow-Origin. (hTsdmdbD8dGSDYWep, line 0)
[Error] XMLHttpRequest cannot load https://app.loya.li/cfs/files/images/hTsdmdbD8dGSDYWep?chunk=0&filename=undefined&token=eyJhdXRoVG9rZW4iOiJBY09oVmpwV0NHbmg5aEh4WllzTWtUTlF4aWs2ZXBjaTRpTVFzdVlfSFBOIn0%3D. Origin http://localhost:12168 is not allowed by Access-Control-Allow-Origin.
[Error] Error: "Queue" network [undefined], n@http://localhost:12168/b116b6c9d7b6379e9b8693b96ac61c52d09c3003.js?meteor_js_resource=true:7:3727
http://localhost:12168/b116b6c9d7b6379e9b8693b96ac61c52d09c3003.js?meteor_js_resource=true:350:3670
http://localhost:12168/b116b6c9d7b6379e9b8693b96ac61c52d09c3003.js?meteor_js_resource=true:350:1025
http://localhost:12168/b116b6c9d7b6379e9b8693b96ac61c52d09c3003.js?meteor_js_resource=true:5:8379
onreadystatechange@http://localhost:12168/b116b6c9d7b6379e9b8693b96ac61c52d09c3003.js?meteor_js_resource=true:350:2333

I added this to App.accessRule('http://localhost:12168'); to my mobile config but I still get the message

[martijnwalraven]

@guidouil: Ah, that is a CORS issue that will have to be solved in the CFS package. The server will have to set the right Access-Control-Allow-Origin header. (App.accessRule('http://localhost:12168') only affects the client and access to the local server is allowed by default.)

It seems there is existing code that allows access to meteor.local, which was used in the old plugin. This will have to be changed to allow localhost:<port>:
https://github.com/CollectionFS/Meteor-http-methods/blob/master/http.methods.server.api.js#L397-L404

[guidouil]

@martijnwalraven and the <port> part is going to be autocompleted or it's a parameter to fetch ? Should it be done in cordova only or accept both always ? thanks

[martijnwalraven]

No, the port will have to be specified. So you may have to look at the Access-Control-Allow-Origin that is sent as part of the request. (Alternatively, you could simply use a * wildcard to allow requests from all origins, but that may not be what you want.)

If you don't know how to do this I could have a look at it and open a pull request. But I will need a way to test this, so preferably a complete project that reproduces your issue.

[markshust]

I'm getting the following error when trying to upload the archive to iTunes Connect:

[guidouil]

@markoshust just remove the icon.png file from the Resources directory in Xcode

[markshust]

@guidouil this actually does appear to be an odd 'bug` in the build process. In XCode/APPNAME/Resources/APPNAME-Info.plist, an 'Icon file' row exists with the value 'icon.png'. Deleting this row gets everything to build ok.

[markshust]

Related to @jhatchr's problem, I also had to set the executable_path to get the app to work when through testflight/connect. It seems like it isn't set by default.

It is set to this:

When default it should be set to this:

Development Target is also not initially set. I believe this should probably be set to 8.0.

Also, there was a 'white flash' after the splash screen and before the initial load takes place. Is there any way to get rid of that?

[jhatchr]

I’m experiencing an issue where all contenteditable=“true” elements are difficult or impossible to tap into and edit in Cordova iOS (pressing down long enough to select the text is the only way to edit the content).

The mobile web version behaves normally on iPhone. I tried to override in CSS and inline HTML with -webkit-user-select: auto but it’s not working. I’m not seeing the issue with input fields.

@martijnwalraven could this have something to do with fastclick 1.0.8-cordova.5?

[markshust]

This could perhaps be related to the icon.png issue, but I'm not getting the correct app icon when double tapping on home to toggle between apps -- looks like I'm getting the default Cordova icon.

[Exilz]

@markoshust There are new icons you need to set with this version

'ios_settings': 'appassets/ios/icon/29.png',
'ios_settings_2x': 'appassets/ios/icon/58.png',
'ios_settings_3x': 'appassets/ios/icon/87.png',
'ios_spotlight': 'appassets/ios/icon/40.png',
'ios_spotlight_2x': 'appassets/ios/icon/80.png',

[JohnBernardsson]

I seem to have some CORS problems too. I am getting these errors:

I20160215-10:10:01.994(1) (android:http://localhost:12352/:0) XMLHttpRequest cannot load http://192.168.0.56:3000/sockjs/info?cb=n1lx0ci8m0. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:12352' is therefore not allowed access.
I20160215-10:10:02.126(1) (android:http://localhost:12352/:0) XMLHttpRequest cannot load http://192.168.0.56:3000/sockjs/info?cb=hbbwsj6yd4. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:12352' is therefore not allowed access.

I think this might be related with https://github.com/meteor/meteor/issues/3382

Then I called meteor run with the option: --mobile-server=https://192.168.0.56:3000 but in this case, I am getting in client the error: Failed to load resource: net::ERR_CONNECTION_CLOSED.

Removing the force-ssl package seems to remove the errors, and let me see a similar error, this time from cfs package, probably same thing @martijnwalraven was pointing:

XMLHttpRequest cannot load http://192.168.0.56:3000/cfs/servertime. The 'Access-Control-Allow-Origin' header has a value 'http://meteor.local' that is not equal to the supplied origin. Origin 'http://localhost:12352' is therefore not allowed access.

Also, in none of my tests I've been able to see anything in the app (just a blank screen after meteor splash image). I am using Angular on the client, and when debugging seems that the html is not being parsed by Angular, and main view is not shown in place. Is this normal because of errors, or should I be worried?

Lot of thanks for the hard work!

[jhatchr]

Following up to my report above regarding contenteditable=“true” elements not being accessible in iOS.

The issue was the same when testing as beta.3, but when testing with --release 1.2.1 - the experience was much improved! That said, in 1.2.1 contenteditable wasn't the same experience as an input field. Using a simulator, 1.2.1 took one long tap to focus and position the cursor on contenteditable vs. an input field where a single normal tap worked fine.

Based on other searches below that point to fastclick, maybe there was a change or omission in the beta plugin?
https://github.com/meteor/meteor/pull/2756 - https://github.com/gadicc/meteor-famous-views/issues/89 - https://github.com/fraywing/textAngular/issues/94 - http://stackoverflow.com/questions/28355957/tapping-in-contenteditable-div-fails-to-position-cursor-when-running-under-cordo

[markshust]

@Exilz thanks so much! this needs to be documented somewhere. however, it does appear that the icon.png issue it still an issue. still need to go into resources and manually delete that plist entry for it to build.

it doesn't appear deployment target is needed anymore.

[jhatchr]

iFrames (used in our app for external Contact Support form) that work in 1.2.1 are not displaying in beta.5

I saw this in the form response headers via Safari X-Frame-Options SAMEORIGIN

Perhaps related to the switch from meteor.local to localhost:<port>?

[jhatchr]

Related to @guidouil @EvilJohnny reports above, I’m seeing the CORS error below when trying to upload a photo via Slingshot:

XMLHttpRequest cannot load https://<bucket>.s3.amazonaws.com/. Origin http://localhost:12448 is not allowed by Access-Control-Allow-Origin.

CORS on S3 was set to meteor.local which worked great. Adjusting the CORS file is easy enough, but left questions...

Setting a wildcard port http://localhost:* isn't valid

Setting it to http://localhost (no port) didn’t work

Setting it to http://localhost:12448 works, but will the port number always be the same for every device the app is installed on and remain the same in future versions? If not, how can we make sure the meteor app origin is allowed by S3 CORS?

@martijnwalraven - is it possible to use a universal localhost port?

Again, thanks for all of the effort on this - we’re excited to be close to releasing our iOS app.

[martijnwalraven]

@jhatchr: The port number is derived from the appId and set at build time, so it will be the same on different devices (always between 12000 and 13000 though). The reason we're not using using just one port is that there may be multiple Meteor apps installed on a single device, and there is a chance they could interfere now that we're using a real local web server.

[jhatchr]

@martijnwalraven That makes sense - thanks!

[jamielob]

@martijnwalraven - I'm also seeing the CORS error that @jhatchr, @guidouil and @EvilJohnny have reported when running on Android.

I20160215-14:26:29.513(-8) (android:http://localhost:12176/signIn:0) XMLHttpRequest cannot load http://192.168.1.84:3000/sockjs/info?cb=nbia3o5ed4. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:12176' is therefore not allowed access. The response had HTTP status code 404.

I'm also seeing the multitasking icon bug that @markoshust reported.

[martijnwalraven]

@EvilJohnny @jhatchr: I've committed a fix (https://github.com/meteor/meteor/issues/1442) for the force-ssl CORS issue, but that won't help you during development. The issue there is that there is no https:// server running on the local development machine, and force-ssl also redirects to the wrong host and port. I'll see if I can make force-ssl prodOnly (https://github.com/meteor/meteor/issues/1442)

@jamielob: Your issue seems to be different. For some reason, the server returns 404 from the sockjs URL. Any chance you are running with nginx or another server in front?

[martijnwalraven]

@jhatchr: The X-Frame-Options SAMEORIGIN is set by the server, so that's where you'd have to make the change. I'm not sure why it worked before, but that could be caused by an iOS upgrade or the switch to WKWebView (meaning the web view didn't respect the X-Frame-Options header before but does now).

[martijnwalraven]

@jhatchr: It seems the issue is indeed related to FastClick. Not sure what causes the difference in user experience with previous versions. Again, could be a change in the web view.

It seems web views are starting to support the touch-action CSS property, which should make FastClick obsolete. I haven't looked into this enough to say whether this is a viable option, but we may be able to switch to a touch-action polyfill: https://github.com/hammerjs/hammer-time

[jamielob]

@martijnwalraven : No server in front but error has disappeared for now so believe it was related to my wifi at the time.

[jhatchr]

@martijnwalraven - I did a quick drop in test of hammer-time.min.js in /lib which didn't fix the contenteditable issue. hammer-time also showed some errors, but might still be worth a better replacement test (I've used hammerjs before and it's great).

I got stuck trying to modify and debug fastclick in Safari similar to the https://github.com/ftlabs/fastclick/issues/127 comment on Nov 12, 2015. My thinking was that instead of using div (we're using h1, div...), perhaps just add a test for target.contenteditable like the below.

Line 261
FastClick.prototype.needsFocus = function(target) {
  if (target.contenteditable){return true;}
  switch (target.nodeName.toLowerCase()) {
   ...
  }
};

Thanks also for the info on iFrame / X-Frame-Options. If I understand correctly, the fix should be straightforward to adjust through browser-policy. I'll update if any issues persist.

[jhatchr]

@martijnwalraven I think there may be an iframe issue. I'm testing with wufoo and vimeo using browser-policy. After setting allowFrameOrigin for both and allowOriginForAll for wufoo (which uses an external script to load the iframe) both display fine in Safari / Firefox / Chrome desktop and both show an iframe element that is empty in Simulator.

In iOS Safari the inspector shows code like below inside <iframe> :

#document
<html>
  <head></head>
  <body></body>
</html>

In desktop Safari it shows

#document
<!DOCTYPE html>
<html ....full correct code

Is it just missing the DOCTYPE for iOS / Cordova?

[martijnwalraven]

A new 1.3 beta which combines modules, mobile, and testing is now available: https://github.com/meteor/meteor/issues/6266

[martijnwalraven]

Going to close this issue because of the new combined beta. But I also think it would be better to have people open new issues from now on instead of commenting on a thread, because that makes it harder to keep track of whether some concern has been addressed.

[dagatsoin]

@martijnwalraven this project becomes better days after days. Congrats !

[martijnwalraven]

Thanks!

[markshust]

@dagatsoin agreed!

thanks for this early beta, i think it's been a big success. already have a 1.3 app approved in the app store because of this :+1:

[martijnwalraven]

@markoshust: Good to hear, you're a brave man :)

[mikepaszkiewicz]

@martijnwalraven Ran into a build error when doing a run ios-device on 1.3, something to do with the sms Cordova plugin and the registry.

While adding plugin [email protected] to Cordova project: Cordova error: Failed to fetch plugin [email protected] via registry. Probably this is either a connection problem, or plugin spec is incorrect. Check your connection and plugin name/version/URL. Error: Registry returned 404 for GET on https://registry.npmjs.org/com.cordova.plugins.sms at registry.fetch.fail.then.pinfo

I'm not exactly sure what depends on this package, but removing it throws an error preventing the xcode build from completing (I am not using ionic):

/Plugins/ionic-plugin-keyboard/IonicKeyboard.m:78:22: Property 'hackishlyHidesInputAccessoryView' not found on object of type 'UIView *'

cordova-plugins:
[email protected]
[email protected]
[email protected]
[email protected]

[martijnwalraven]

@mikepaszkiewicz: The use of the Cordova plugin registry has been discontinued, and plugins have moved to npm. As a result, older versions of plugins are often no longer available. Many plugins have also changed their names to be in more in line with conventions.

As far as I can see, [email protected] would be the replacement. Not sure if that solves the problem with ionic-plugin-keyboard.

[DanielDornhardt]

Hello everybody,

TL;DR: We want to set cookies on our XHR (AJAX) - Requests to the server from Android Platform 23 Cordova Devices.

(Cross-posted to https://forums.meteor.com/t/meteor-1-3-beta-11-setting-cookies-from-cordova-on-android/18637)

---

Longer Version:

We want / need to authenticate our user from our cordova app on our server. The problem is we're using a custom request handler to upload files (a fork of https://github.com/vsivsi/meteor-file-collection). The way to supply user authentication information we used so far was using the cordova-cookie-master-package (https://github.com/kristianhristov/cordova-cookie-master) to set these cookies on XHR (AJAX) Requests requests to the server.

With Meteor 1.3 Beta 11 the android SDK Platform API Version has been upped to 23. Unfortunately, with this the Apache HTTP Client support has been nixed: http://developer.android.com/about/versions/marshmallow/android-6.0-changes.html#behavior-apache-http-client on which the cookie-master - package relied to set the cookies.

So the question is now: How can we send additional authentication information to the Server?

We could probably encode it in the request URL, which is what I'll be doing as a temporary hack; But besides that it seems that our options are very limited (most outgoing headers seem to be filtered / whitelisted?).

It'd be nice if there'd be a way to add the cookie information back to the XHR Requests.

One temporary workaround would be to add the following to the build-extras.gradle.txt - file:

ext.postBuildExtras = 
{
android {
    useLibrary 'org.apache.http.legacy'
    println('useLibrary org.apache.http.legacy');
    }
}

to add the legacy support for HTTP back into the project for android. But I don't think there's a setting in mobile_config.js to do that, or is there?

Could anybody point me to some workable options? I'd prefer to stick to the meteor build process in the most part, but if there are some workarounds including step-by-step-instructions i'd be interested too.

[martijnwalraven]

@DanielDornhardt: I did some testing, and with the right CORS headers it seems you can definitely send additional headers (tested on iOS 9 and Android 5.1). You can also send cookies, but you can't set cookies for other domains from JavaScript, so the server would have needed to set the cookie in a previous response. I've included some sample code, but you may want to have a look here for more details.

On the client:

var xhr = new XMLHttpRequest();
xhr.open("GET",  __meteor_runtime_config__.ROOT_URL + "cookietest", true);
// Only needed for cookies
xhr.withCredentials = true;
xhr.setRequestHeader("Authorization", "bla");
xhr.onreadystatechange = function() {
  if (xhr.readyState === XMLHttpRequest.DONE && xhr.status === 200) {
    console.log(xhr.responseText);
  }
};
xhr.send();

On the server:

WebApp.connectHandlers.use("/cookietest", function(request, response, next) {
  // We need to echo the origin provided in the request
  var origin = request.headers.origin;
  if (origin) {
    response.setHeader("Access-Control-Allow-Origin", origin);
  }

  // Only needed for cookies
  response.setHeader("Access-Control-Allow-Credentials", "true");

  // For the preflight
  if (request.method == "OPTIONS") {
    response.setHeader("Access-Control-Allow-Headers", "authorization");
  }

  response.writeHead(200, {'Content-type': 'text/plain'});

  // For the actual response
  if (request.method == "GET") {
    var authorization = request.headers.authorization;
    response.write("Hello " + authorization);
  }
  response.end();
});

[DanielDornhardt]

Hello @martijnwalraven , you're right, thank you very much!

CORS is of course possible the way you do it, and I should be able to supply the authentication information as in your example. I was missing the "Access-Control-Allow-Headers", "authorization" - header I think.

This means I won't need the cookies for my current endeavor, which is nice!

---

About being able to set cookies via a server response: That's great, but probably not what we'd need.

But you think it should be possible to make Cross-Domain Requests from Cordova with credentials and in return we'd get those cookies set persistently for our app? That'd be a nice thing to have in any case!

---

So, thank you very much for your help, I'll waltz through the third-party-code on monday and patch the heck out of it, and we'll be using the glorious Meteor Beta 1.3! :D

[DanielDornhardt]

Another question: File URL / Cordova - File - URL for files in Meteor /public/ - Folder?

With Meteor 1.3 Beta 11 (We didn't try the earlier betas), we want to load and play sounds using cordova-plugin-media-with-compression .

Bevor 1.3 we used this URL as Media url to load: 'http://meteor.local' + pathInPublicFolder .

Now, when trying to use document.location.origin (basically protocol + domain + port) + pathInPublicFolder, this only seems to work on android.

How do we access the Meteor /public/ - files via file:// URL? Is there something in the cordova-file-plugin we can use?

Thanks and best wishes - great job with 1.3 in general so far I have to say, big respect, most things look really cleaned up and more stable so far!

[martijnwalraven]

@DanielDornhardt: Thanks, glad to hear you're happy with the changes!

You should be able to access files in the /public directory as you did before, except meteor.local changed to localhost:<port>. What happens on iOS? Any errors in the browser console? It might be an issue specific to the plugin. Have you tried using an <audio> tag?

[DanielDornhardt]

Hi @martijnwalraven , using an audio tag like this: a = new Audio('http://localhost:12224/sfx/plop.mp3'); a.play() doesn't seem to do much, at least I can't hear anything.

Doing something like this:

        this._mediaReference = new Media('sfx/plop.mp3',
            // success callback
            function() {},
            // error callback
            function(err) {
                log('error playing back sound effect', err)
            }
        )

or this url (instead of 'sfx/plop.mp3') doesn't work either: 'http://localhost:12224/sfx/plop.mp3' .

With android the same (the last) URL works.

It's quite possible it's the way the plugin loads the file (?).

If I load the file from the server it works as well (using eg. 'http://192.168.178.24:3000/sfx/plop.mp3'). So it's a loading issue and probably not a decoding / playback issue I think.

Interestingly the error messages differ, if I use the http://localhost:port - version I get these:

2016-02-29 21:44:01.327 alphastreamsm13l[5849:6975876] Failed to initialize AVAudioPlayer: The operation couldn’t be completed. (OSStatus error 2003334207.)
2016-02-29 21:44:01.328 alphastreamsm13l[5849:6975876] THREAD WARNING: ['Media'] took '53.217041' ms. Plugin should use a background thread.
2016-02-29 21:44:01.377 alphastreamsm13l[5849:6975876] ["error playing back sound effect \"http://localhost:12224/sfx/plop.mp3\"",{"message":"","code":4}]

And if I only user 'sfx/plop.mp3' I get these:

2016-02-29 21:53:10.631 alphastreamsm13l[5849:6975876] Will attempt to use file resource 'sfx/plop.mp3'
2016-02-29 21:53:10.632 alphastreamsm13l[5849:6975876] Unknown resource 'sfx/plop.mp3'
2016-02-29 21:53:10.641 alphastreamsm13l[5849:6975876] ["error playing back sound effect",{"message":"Cannot use audio file from resource 'sfx/plop.mp3'","code":1}]

But it's not a lot of difference I think.

I don't have enough time (and not enough knowledge about cordova internals) to look deeper into it unfortunately. If anybody has an idea or tipps I'll gladly try them out! :)

Best wishes and have a great week, @martijnwalraven and everybody else as well. :)

[danlg]

@martijnwalraven I can see there is some nice doc going for 1.3 which is a very good thing. http://guide.meteor.com/v1.3/1.3-migration.html. However, there is no guide or doc for mobile which has been so far the Meteor's Achilles heel (understand there will be a section on that focusing on Cordova). Would MDG consider writing more Mobile doc for 1.3. Some details on the below would be appreciated - in addition to Cordova:

• build system build and the mess due to server url see #3594 (when building we want to be able to build to UAT and promote a UAT to prod not have to rebuild, this is just config).
• autoupdate: very big changes worth a section
• WKWebview impact if any e.g. ionic or best pratice to mitigate ?
• CrossWalk integration: I know it is not new in 1.3 but not clear whether we can support both crosswalk for android and WKWebview with same build config
• production deployment for mobile (if different with web deployment): Cordova client & server
• Best practice / Warning / advice would be super appreciated

Thanks.

[martijnwalraven]

@danlg: Working on the mobile guide right now! I should have at least a basic version ready in time for 1.3.

I do have some questions about the specific points you mention:

• I'm not sure what the proposal is in #3594. Meteor mobile apps need a server URL as part of the build, because otherwise they wouldn't be able to connect to the server for data and hot code push.
• What do you mean by 'e.g. ionic or best pratice to mitigate'?

[mikepaszkiewicz]

@martijnwalraven I revisited the previously mentioned bug - changing the version number on iOS did allow the project to build successfully. However when I run the project in xCode I'm still getting

/Plugins/ionic-plugin-keyboard/IonicKeyboard.m:78:22: Property 'hackishlyHidesInputAccessoryView' not found on object of type 'UIView *'

I can't find any mention or reference to IonicKeyboard in the project, how would I go about finding what is calling / requiring it?

[Hamatek]

I thought the new version of meteor and the updated cordova version would speed up to startup time of an android meteor app, but it doesn't seems to be any faster still getting a 10s delay(on the splashscreen) even with settings like : App.setPreference('splashScreenDelay', '3000'); in mobile-config.js anyone solved this issue @mscherer82 ?

[mscherer82]

@Hamatek : Are you using angular and ionic? It seems that the splash screen will not be hidden when the app is loaded. Thats why you get exactly 10 secs.
Worked for me:

if(Meteor.isCordova) {
        $ionicPlatform.ready(function () {
                navigator.splashscreen.hide();
        });
   }

[Hamatek]

@mscherer82 thanks for your quick reply, actually im not using angular nor ionic, just materializecss +react+flow-router and the new meteor 1.3.
Thanks for sharing your solution Ill look into it maybe I can manually hide the splashscreen with sth like this :

//on client
Meteor.startup(() => {
  document.addEventListener("deviceready", function() {
    navigator.splashscreen.hide();
  }
}

@mscherer82 thanks to you the splashscreen now disappear after 4s!! :dancers:

Update: Actually the code above crash ios app on start so now I tried to update the cordova-plugin-splashscreen with : meteor add cordova:[email protected]
and I have added the following in the mobile config

//on mobile-config.js
App.setPreference('SplashScreenDelay', '3000');
App.setPreference('AutoHideSplashScreen', 'true');

[msavin]

I'm excited to get this production with this!

I've noticed that meteor run ios starts as 6S Plus - any way to change that to a 6S? The Plus resolution is hard to manage after all the hacks Apple put it through, but the 6S fits nicely on the screen, and is a good model to target as its their most popular product.

[martijnwalraven]

@msavin: You may want to use meteor run ios-device to open the project in Xcode. That way, you get a full choice of simulators and can even create new ones yourself.

[msavin]

I'm also seeing that it requires you to be on a wi-fi network for it to work. I've been able to use the "Create Network" option when I am offline, but that's not preferable because you leave an open network. (AFAIK, "Create Network" cannot be password protected, or the option for it is poorly hidden). Is there another way here?

@martijnwalraven just saw the new comment; thanks for the tip

[martijnwalraven]

Ah, you're right, ios-device does fail when it can't detect a network address. As a workaround, you should be able to use meteor run ios-device --mobile-server localhost:3000 however.

[msavin]

Nice 😊

I've got many more of these haha. I checked the Meteor documentation, but Cordova mentions are limited. Have I missed it, or will there be a new documentation for Cordova?

[martijnwalraven]

You may have missed it, there is a whole new mobile guide!

[msavin]

Word - so... this is the last one I promise! It may be helpful to address in docs.. how does hot code push work now?

Originally, I'd see the assets download in the console logs in Meteor 1.2, and then I had Reload.isWaitingForResume() to see the state. However, I wonder if that has completely changed in the new implementation. It also makes me wonder if mdg:reload-on-resume is functional as it has not been updated in about a year.

This may be because I am not able to get HCP to work. In console I see an error: Error: Error parsing asset manifest: Error Domain=NSCocoaErrorDomain Code=3840 "JSON text did not start with array or object and option to allow fragments not set." UserInfo={NSDebugDescription=JSON text did not start with array or object and option to allow fragments not set.}

Reloading, etc, is not doing much unfortunately. Usually, it just kinda worked automatically.

[martijnwalraven]

mdg:reload-on-resume should still be functional, the reloading mechanism itself hasn't changed.

Are both server and client app on Meteor 1.3? How are you running Meteor?

[markshust]

@msavin I wondered the same thing. mdg:reload-on-resume does in fact still work. I have it working in a production app now (yea, I was crazy for setting this all up a couple months ago, but am reaping the benefits now :+1: ). I'm not sure what your issue is.

[msavin]

Hmm, well at this point I must be tripped out by the hot code push. 😅 It's Meteor 1.3 (without modules/es6) on the server, and then a new Cordova build after running meteor run ios-device (cordova.version returns 4.1.0). I'll toy with it some more and circle back if I can or can't find the problem.

[msavin]

Removed mdg:reload-on-resume and re-built; no difference. Ran meteor run ios-device --mobile-server localhost:3000, then canceled the server to run it in development mode (it seemed to have been running in production mode as debugOnly stuff was missing) - HCP did not work. Ran meteor run ios and now HCP is working. I'll update if I learn something new.

@markoshust to confirm - are you able to do HCP with Cordova 4.1.0 on Meteor 1.3 in production?

Edit for MDG people: turning off wi-fi in favor of using "Create a Network" broke the connection from Meteor to Cordova.. reconnecting to original network fixed it.

Additionally, this error went away: Error: Error parsing asset manifest: Error Domain=NSCocoaErrorDomain Code=3840 "JSON text did not start with array or object and option to allow fragments not set." UserInfo={NSDebugDescription=JSON text did not start with array or object and option to allow fragments not set.}

On the bright side, HCP and rebuilds got much faster!

[markshust]

@msavin yes, it is working for me through testflight and the App Store. Here is the code I'm using:

import {Reload} from 'meteor/reload';
import {Tracker} from 'meteor/tracker';
import {FlowRouter} from 'meteor/kadira:flow-router';
import showLoadingThenReload from '../imports/show-loading-then-reload';

// Let's manually check for update when on home screen, and reload if there is one
Tracker.autorun(() => {
  const current = FlowRouter.current();
  const currentRouteName = current.route && current.route.name ? current.route.name : '';

  FlowRouter.watchPathChange();

  // We need this here because an update is available
  // and we don't want to wait for resume to reload on these routes
  if (Reload.isWaitingForResume()
    && currentRouteName == 'home'
  ) {
    showLoadingThenReload();
  }
});

then in showLoadingThenReload:

import {FlowRouter} from 'meteor/kadira:flow-router';

const showLoadingThenReload = () => {
  FlowRouter.go('loading');

  // Timeout to show loading animation
  window.setTimeout(() => window.location.replace('/'), 2000);
};

export default showLoadingThenReload;

Note that this is only triggered on route changes, so I also added something to my home component to trigger within a reactive function. I'm using TrackerReact in a few places:

import React from 'react';
import {Reload} from 'meteor/reload';
...
import TrackerReact from '../../ultimatejs-tracker-react/client/tracker-react-mixin';
import showLoadingThenReload from '../../reload/imports/show-loading-then-reload';

const HomeContainer = React.createClass({
  mixins: [TrackerReact],

  data() {
    ...
    // We need this here because an update is available
    // autorun.js potentially isn't triggered on initial load
    if (Reload.isWaitingForResume()) showLoadingThenReload();

    return {
      ...
    };
  },

[codeNgamer]

@markoshust

Also, there was a 'white flash' after the splash screen and before the initial load takes place. Is there any way to get rid of that?

were you able to resolve that? tried LaunScreen.hold() from: https://forums.meteor.com/t/resolved-meteor-1-3-rc-12-splash-screen-do-not-follow-autohidesplashscreen-false/20105 with no luck

[markshust]

@codeNgamer no I haven't resolved that yet, still happens. this did use to happen on meteor 1.2 but was fixed at some point, perhaps someone can lookup what that changeset was and see if it's applicable here. note that this is only noticeable with apps that have a dark/black background.

[mikepaszkiewicz]

+1, got this on 1.2 w/ dark background, but it stopped eventually, seems to be back.

[codeNgamer]

@markoshust @mikepaszkiewicz so i just got this working with this in mobile-config

App.setPreference('AutoHideSplashScreen', false);
App.setPreference('ShowSplashScreenSpinner', true);
App.setPreference('FadeSplashScreenSpinner', 2000);

then in client/lib/config.js i've got this before everything else, this shouldnt go in Meteor.startup too cause that'll wait for deviceready

if (Meteor.isCordova && navigator) {
 navigator.splashscreen.show()
}

Finally, on my template rendered function or alternatively, componentDidMount for react, i've got

navigator.splashscreen.hide()

hope that solves for you guys

[markshust]

@codeNgamer brilliant!! this solves another workflow issue i had where i didn't want to show the app until it checks for updates (via reload-on-resume). going to apply the same logic to that. cheers...

[codeNgamer]

@markoshust cool man, glad i could help

[markshust]

@codeNgamer i like the logic you laid out, however i'm still getting a white flash with this. do i need to install any cordova plugin for navigator.splashscreen?

[codeNgamer]

@markoshust yeah my bad, forgot to mention i've got [email protected]

[markshust]

@codeNgamer for what it's worth, I couldn't get that working either (even though that appears as a pre-installed meteor/cordova plugin?). anyways, I got rid of the white splash with the launch-screen package. no cordova or etc. needed, the api is super simple also. https://github.com/meteor/meteor/tree/devel/packages/launch-screen

i created a client/main.js file:

import {LaunchScreen} from 'meteor/launch-screen';

const handle = LaunchScreen.hold();

export default handle;

then imported it to my layout files. note however though that i did have to add in a 1-sec timeout/delay in order for it to work correctly, perhaps a bug with that package.

import handle from '../../launch-screen/client/main';
...
  componentDidMount() {
    window.setTimeout(() => handle.release(), 1000);
  },

thought this may be useful to anyone else who came across this.

[jamielob]

FYI @markoshust, the launch-screen package uses the cordova-plugin-splashscreen. I'm looking in to the white flash problem at the moment also.

[jamielob]

https://forums.meteor.com/t/resolved-meteor-1-3-rc-12-splash-screen-do-not-follow-autohidesplashscreen-false/20105

[jamielob]

After chatting with @lorensr, I'm building a package that will give people a lot more options for how and when code is pushed and how the splash screen is used in those instances:

https://github.com/jamielob/reloader

Please feel free to join the discussion in the issues over there if you would like to make sure that your use case is covered.

[martijnwalraven]

@jamielob: Great initiative, thanks! Let me know if you have questions or need anything from me.

[jamielob]

Thanks @martijnwalraven! You were instrumental in finding this issue:
https://github.com/jamielob/reloader/issues/2

Anything I can do to help that PR get merged?

[martijnwalraven]

@jamielob: Merged :)

[shahidkarimi]

I still get this message "This command is not yet available on Windows."

please tell me exact command to run my thing. Not long explanatory text. please @martijnwalraven

[martijnwalraven]

@shahidkarimi: Are you sure you are using Meteor 1.3?

[jjc12]

@Martijnwalraven I'm getting the same error, and I am running Meteor 1.3.2.4.

See: http://i.imgur.com/ibX4Ywx.png