phonegap device ready event not firing on Android WebApp (delivered from the server)

[Jammu]

Hi,

I'm having issues with the phonegap device ready event not firing when the Web App is delivered by the server.

the App config.xml points to index.html on the server instead of on the local file system. So, the whole app, with all the required Javascript files are downloaded from the server.

When this happens the cordova device ready doesn't fire.

Here are the logs from Chrome console.

plugins/cordova-plugin-console/www/console-via-logger.js:173 deviceready has not fired after 5 seconds.

plugins/cordova-plugin-console/www/console-via-logger.js:173 Channel not fired: onCordovaInfoReady

plugins/cordova-plugin-console/www/console-via-logger.js:173 Channel not fired: onFileSystemPathsReady

plugins/cordova-plugin-console/www/console-via-logger.js:173 Channel not fired: onCordovaConnectionReady

Any ideas why this could be happening?

Note that this problems happens only on Android and only when the App is delivered by the server. When the app is accesses from the local file system in the package everything works fine.

Also I'm not seeing this problem on iOS. The app with phonegap on iOS works fine with the app delivered by the server.

I'm completely stumped with this problem. Any help would be very appreciated.

[Jesse Monroy]

@Jammu,
Phonetgap was NEVER intended to work that way. The best way to build a phonegap App is to have as many components as you can on the device - MOST of all phonegap.js must be on the device. It should not be loaded from a server.

Jesse

[Jammu]

Thanks Jesse.

It seems to work quite well on iOS though. So I was wondering what is about Android that is preventing it. 

Also, I'm using the HTML5 cache so once the scripts are downloaded, second time around, it doesn't even make a web request to the server and loads the scripts locally. Still it does not work (only on Android). 

Any ideas why specifically?

[Jesse Monroy]

Your Question:

>>Any ideas why specifically?

That's because it is NOT designed to work that way.

This is annoying. Do you guys ever do ANY work?
If you had, then you'd know that you should load locally. Just because it is working on iOS does NOT mean it will work in other places.

Did you read the FAQ?
http://phonegap.com/about/faq/

Do you read the docs?
http://docs.phonegap.com/en/3.3.0/

Are you using Phonegap CLI? or Phonegap Build?

Even if you load from a server, you'll likely get rejected by Google and Apple.
They want mobile Apps, not web Apps.

Someone else will answer any other questions you have.

Best of Luck
Jesse

[Jammu]

Hi Jesse,

Thanks for the feedback on my question. I seem to have touched a wrong nerve which was certainly not my intent.

I'm new to the area of Hybrid Apps and therefore I'm asking these questions. Let me assure you that, while I'm not afraid of asking stupid questions, I'm certainly not stupid. :)

The reason I ask is this:

I'm most excited about phonegap and hybrid apps for two main reasons:

#1. Platform independence and standard technologies (of course, that's a no-brainer)

#2  The ability to live update an app. Now this area seems to be controversial. 

I feel, in todays landscape of mobile apps, the pace of innovation is crucial to stay relevant and win.

I think #1 and #2 combined make hybrid apps extremely powerful. Just doing #1 takes the fight with Native Apps to their playing field in which they are very strong. 

1+2 however takes the fight to a field where Hybrid Apps and web technologies have a huge leg up over native apps. 

Also, there is a big precedence - web delivered apps on the desktop for example. 

As I started looking into the "ability to do live updates" I did find there references (to name a few).

http://kindofcode.com/ionic-hot-code-push/

http://blog.peterkim.co/tutorial-how-to-add-onthefly-updates-to-a-hybrid-app

Also ionic and phongegap Hydration provide live updates of the app.

Are these guys doing something wrong? I could certainly be missing something. 

When I experimented with these methods I was delighted that it worked on iOS but found out it didn't on Android. And that's the point I posted the question.

Regarding your comment about "That's because it is NOT designed to work that way."

Wasn't phonegap itself born by challenging the status-que of "that's not how it's done" ?

Would love to hear, exactly what can I do to implement "live update" of my hybrid app on Android.

cheers!

[Kerri Shotts]

Jammu,

Apple has only recently changed their position on live updates with apps, so we're all treading in some new territory here as to what Apple will and won't accept. I think as long as you don't make an update that fundamentally changes your app (say from a chat app to minecraft clone), the concept itself is probably safe.

As to doing live updates, the catch is this: the code is still all local. That is, when an update is performed, the code is downloaded and stored local to the device (typically in a cache). In that sense, the code does not /run/ from the server -- it runs /locally/.

Now, your question was specifically about having problems with cordova.js from the server. Well -- there are a lot of problems doing that, security notwithstanding. For one, cordova.js is /different/ for every platform. For example, I have a fairly simple test app that I use to play around with sometimes, and the cordova.js version is definitely different. For android, it's something like 64K, while on iOS, it's 58K. That alone should tell you that something platform-specific is going on. Furthermore, cordova.js varies by platform version (for my project, I have i...@3.8.0, and And...@4.0.2)

In order to make things work correctly, you'd have to provide at least two versions of cordova.js, and have some local code to determine which one to use (or some network code that sniffs the device and serves the appropriate file). But you have another problem: if you are running from the server, what happens when the user has no network connection?

Apple requires apps to serve useful error messages when this occurs -- even something as simple as "This app requires an internet connection" is fine. But if all your code is remote, you may never have the opportunity to generate this message. So, at minimum, you need /some/ local code. Personally, the experience is much better (in my opinion) if you keep as much code local as you can. That doesn't mean you can't update it, just that the code you run should be local to the device.

That's what hydration and ionic's stuff does (or rather, should be doing: I don't use it), and I'd suggest going with something like that rather than building your own. The reason is security: you have to worry about properly securing that communication between your user's device and the source code. If the code was downloaded incompletely or in a corrupted form, would you catch it? What if there was a man-in-the-middle? Would you be able to detect that the code the user received was the same code you expected them to receive? The security here gets painful, and is one of many reasons why I suggest staying away from live updates entirely, but if you must do it, to NOT use something that's home-grown.

(I also have a third reason: I don't like apps to be updated without my permission. After all, there may be a very good reason I've not updated yet: bugs, lost/changed features, etc.) Reaching in and updating my app without my consent feels like it crosses a line. But that's my opinion.)

One more reason: if you ever update your plugins, you'll need to deploy a regular update anyway. Live updates can only transfer www code, not native code.

I hope that helps.

[Jesse Monroy]

@Kerri,
Thanks for taking this queston.

@Jammu,
regardless of which platform (or software solution) you plan on using (or are investigating), there is an FAQ available. This is the reason that FAQs are written. In addition, this question (you asked), gets asked every day. If you'd read the forum you see this. If you'd read the FAQ, you  know this. If it is not clear, then ask questions about the confusion. We are certainly aware that not every person understands every explanation. We only have so much patience on this question and other questions that are in the FAQ.

Lastly, we do write blogs to help clarify things.
Here is a very good blog from one member.
https://iphonedevlog.wordpress.com/

Best of Luck
Jesse

[Jammu]

Thanks Kerri for the detailed, extremely helpful feedback and for listing out all the pitfalls. Especially thank you for your professional and respectful reply. 

Please see some comments inline.

regards

On Tuesday, July 21, 2015 at 12:40:56 PM UTC-7, Kerri Shotts wrote:

Jammu,

Apple has only recently changed their position on live updates with apps, so we're all treading in some new territory here as to what Apple will and won't accept. I think as long as you don't make an update that fundamentally changes your app (say from a chat app to minecraft clone), the concept itself is probably safe.

 

As to doing live updates, the catch is this: the code is still all local. That is, when an update is performed, the code is downloaded and stored local to the device (typically in a cache). In that sense, the code does not /run/ from the server -- it runs /locally/.

Yes, exactly right. We use the HTML5 cache events to download the files and then restart the app once it's completely downloaded. 

 

Now, your question was specifically about having problems with cordova.js from the server. Well -- there are a lot of problems doing that, security notwithstanding. For one, cordova.js is /different/ for every platform. For example, I have a fairly simple test app that I use to play around with sometimes, and the cordova.js version is definitely different. For android, it's something like 64K, while on iOS, it's 58K. That alone should tell you that something platform-specific is going on. Furthermore, cordova.js varies by platform version (for my project, I have i...@3.8.0, and And...@4.0.2)

Makes perfect sense. Yet, Security/Auth etc is application level and applies to even pure Web Apps that have nothing to do with cordova. 

Yes, indeed. Platform specific cordova versions is certainly an added complication. 

In order to make things work correctly, you'd have to provide at least two versions of cordova.js, and have some local code to determine which one to use (or some network code that sniffs the device and serves the appropriate file). But you have another problem: if you are running from the server, what happens when the user has no network connection?

 

When the user has no network connection the app works out of the HTML cache. We test it regularly on iOS. 

Do you think there might be still some issues with that?

 

Apple requires apps to serve useful error messages when this occurs -- even something as simple as "This app requires an internet connection" is fine. But if all your code is remote, you may never have the opportunity to generate this message. So, at minimum, you need /some/ local code. Personally, the experience is much better (in my opinion) if you keep as much code local as you can. That doesn't mean you can't update it, just that the code you run should be local to the device.

Yeah, first time the user logs in the code is remote but at the time of logging in they need network access anyway. After first login there is always a copy of the code locally in the HTML cache. 

Again, the code is always local unless the server tells the client that there is an update. In that case the client checks the HTML5 manifest files, updates the cache in the background and restarts the app. 

Btw, just today, gmail did that for me when I logged into this forum. :)

That's what hydration and ionic's stuff does (or rather, should be doing: I don't use it), and I'd suggest going with something like that rather than building your own. The reason is security: you have to worry about properly securing that communication between your user's device and the source code. If the code was downloaded incompletely or in a corrupted form, would you catch it? What if there was a man-in-the-middle? Would you be able to detect that the code the user received was the same code you expected them to receive? The security here gets painful, and is one of many reasons why I suggest staying away from live updates entirely, but if you must do it, to NOT use something that's home-grown.

(I also have a third reason: I don't like apps to be updated without my permission. After all, there may be a very good reason I've not updated yet: bugs, lost/changed features, etc.) Reaching in and updating my app without my consent feels like it crosses a line. But that's my opinion.)

Yeah, good to know about peoples preferences. 

 

One more reason: if you ever update your plugins, you'll need to deploy a regular update anyway. Live updates can only transfer www code, not native code.

True. Live updates are for quick iterations and bug fixes. If and when plugins are updates we will have to push a full update.

 

I hope that helps.

It certainly helps and thank you again for all the great points you have made. 

Yet, I feel those are all technical complexities that are around putting any major app into production which can be handled with proper investment.

Aside from that, at least in test and dev, we see huge benefit. Would you also agree? Everything is trusted in the local network and  platform dependence can be carefully managed. We have only a small set of devices. This process had significantly speeded up our test/dev on iOS.

Even with all those complications, I'm still wondering what is it preventing cordova to startup on Android. 

In one case cordova plugins are accessed from the application file system, in the other they are accessed from the HTML cache. 

Again, we have no issues with cordova on iOS. Is it timing related or something more fundamental about Android?

Would love to hear your thoughts/perspective on that.

Lastly, please understand, these questions are coming from real needs and I'm not trying to point any fingers or upset anyone. I have dug around into all the documents that I have been asked to read but I have not found anything that addresses the issue. If I have missed it somehow, can you send me a specific link?

My apologies in advance if this technical dialog upsets anyone.

Regards

J

[Kerri Shotts]

See inline, in RED:

On Wednesday, July 22, 2015 at 12:07:00 PM UTC-5, Jammu wrote:

Thanks Kerri for the detailed, extremely helpful feedback and for listing out all the pitfalls. Especially thank you for your professional and respectful reply. 

Please see some comments inline.

You're welcome. Not sure how much my comments below will help, but hopefully they can be of assistance.

 

regards

On Tuesday, July 21, 2015 at 12:40:56 PM UTC-7, Kerri Shotts wrote:

Jammu,

Apple has only recently changed their position on live updates with apps, so we're all treading in some new territory here as to what Apple will and won't accept. I think as long as you don't make an update that fundamentally changes your app (say from a chat app to minecraft clone), the concept itself is probably safe.

 

As to doing live updates, the catch is this: the code is still all local. That is, when an update is performed, the code is downloaded and stored local to the device (typically in a cache). In that sense, the code does not /run/ from the server -- it runs /locally/.

Yes, exactly right. We use the HTML5 cache events to download the files and then restart the app once it's completely downloaded. 

 

Now, your question was specifically about having problems with cordova.js from the server. Well -- there are a lot of problems doing that, security notwithstanding. For one, cordova.js is /different/ for every platform. For example, I have a fairly simple test app that I use to play around with sometimes, and the cordova.js version is definitely different. For android, it's something like 64K, while on iOS, it's 58K. That alone should tell you that something platform-specific is going on. Furthermore, cordova.js varies by platform version (for my project, I have i...@3.8.0, and And...@4.0.2)

Makes perfect sense. Yet, Security/Auth etc is application level and applies to even pure Web Apps that have nothing to do with cordova. 

I'm not talking so much about authorization / authentication (though that is a problem), but simply the security regarding the transfer of your code. You really need some client-side code that can make sure that the downloaded code is what you expect to be downloaded. For example, what if the user only receives a partial JS file? The app will fail to work, obviously. What if the user doesn't actually have enough space for the code you're downloading? Or, more worrisome: what if a MITM attack inserts a malicious file? That's why I suggest using a well-established third party solution rather than rolling your own.

 

Yes, indeed. Platform specific cordova versions is certainly an added complication. 

Which, I think, Is why @Jesse indicates that PG really wasn't designed for /this/ use. PG expects cordova.js to match the platform it is running on.

 

In order to make things work correctly, you'd have to provide at least two versions of cordova.js, and have some local code to determine which one to use (or some network code that sniffs the device and serves the appropriate file). But you have another problem: if you are running from the server, what happens when the user has no network connection?

 

When the user has no network connection the app works out of the HTML cache. We test it regularly on iOS. 

Do you think there might be still some issues with that?

What about the first time, when the user has nothing in the cache? Or what if the app is started after iOS has cleared the app's cache (which it can do if space is low)? Without at least some basic client-side code that performs the download, you won't be able to present any good warnings to the user.

 

 

Apple requires apps to serve useful error messages when this occurs -- even something as simple as "This app requires an internet connection" is fine. But if all your code is remote, you may never have the opportunity to generate this message. So, at minimum, you need /some/ local code. Personally, the experience is much better (in my opinion) if you keep as much code local as you can. That doesn't mean you can't update it, just that the code you run should be local to the device.

Yeah, first time the user logs in the code is remote but at the time of logging in they need network access anyway. After first login there is always a copy of the code locally in the HTML cache. 

Yes, but Apple doesn't care: if the user doesn't have Internet access at this time, they should be given an appropriate message. If there's no code locally on the device, how will the user be notified? This doesn't mean that your app has to work a miracle: no internet access means an app that can't function. But the user should see a useful error message like "This application requires access to the Internet in order to function. If you have turned on Airplane mode, please turn it off before continuing."

 

Again, the code is always local unless the server tells the client that there is an update. In that case the client checks the HTML5 manifest files, updates the cache in the background and restarts the app. 

What do you mean by "restarts the app"? Is this something the user notices? Is it a forced restart, or something the user has control over?

 

Btw, just today, gmail did that for me when I logged into this forum. :)

That's what hydration and ionic's stuff does (or rather, should be doing: I don't use it), and I'd suggest going with something like that rather than building your own. The reason is security: you have to worry about properly securing that communication between your user's device and the source code. If the code was downloaded incompletely or in a corrupted form, would you catch it? What if there was a man-in-the-middle? Would you be able to detect that the code the user received was the same code you expected them to receive? The security here gets painful, and is one of many reasons why I suggest staying away from live updates entirely, but if you must do it, to NOT use something that's home-grown.

(I also have a third reason: I don't like apps to be updated without my permission. After all, there may be a very good reason I've not updated yet: bugs, lost/changed features, etc.) Reaching in and updating my app without my consent feels like it crosses a line. But that's my opinion.)

Yeah, good to know about peoples preferences. 

 

One more reason: if you ever update your plugins, you'll need to deploy a regular update anyway. Live updates can only transfer www code, not native code.

True. Live updates are for quick iterations and bug fixes. If and when plugins are updates we will have to push a full update.

 

I hope that helps.

It certainly helps and thank you again for all the great points you have made. 

Yet, I feel those are all technical complexities that are around putting any major app into production which can be handled with proper investment.

Yes: which is why I suggest using well-established solutions if you must live update your app. I'd advise against building your own: you almost certainly will have missed some edge cases.

 

Aside from that, at least in test and dev, we see huge benefit. Would you also agree? Everything is trusted in the local network and  platform dependence can be carefully managed. We have only a small set of devices. This process had significantly speeded up our test/dev on iOS.

For test and dev, absolutely. That's why I like the PhoneGap Developer app, and why PG Build offers Hydration and other services do similar things. It certainly speeds up development. The hard question is whether or not you're willing to use it in production or not, and that's something you'll want to ensure is stable, secure, and very well tested.

 

Even with all those complications, I'm still wondering what is it preventing cordova to startup on Android. 

In one case cordova plugins are accessed from the application file system, in the other they are accessed from the HTML cache. 

Again, we have no issues with cordova on iOS. Is it timing related or something more fundamental about Android?

I suspect you're serving the wrong cordova.js file. If Android is trying to use the iOS cordova.js file, I would expect problems. Furthermore, cordova.js is tied to the native bits: so if your native bits ever change, cordova.js has to change along with them. Serving this from your server is going to be far more trouble than it is worth, which is why I'd suggest using Hydration or the like.

Without knowing more about how your app is transferring your files, and how they are structured, it's hard to say anything beyond that. It might help to see your index.html file... Are you getting anything on any consoles? adb logcat? web developer console? 

 

Would love to hear your thoughts/perspective on that.

Lastly, please understand, these questions are coming from real needs and I'm not trying to point any fingers or upset anyone. I have dug around into all the documents that I have been asked to read but I have not found anything that addresses the issue. If I have missed it somehow, can you send me a specific link?

My apologies in advance if this technical dialog upsets anyone.

 

Hope that helps? If not, feel free to ask for clarification/etc. 

Regards

J

[Jesse Monroy]

@Kerri
you are wasting your time. This person wants a solution that phonegap was not designed for. Even if this person manages to do things the way they want, it will be a messy solution and unreliable. Lastly, we're mostly consultants here. Hand holding requires $$$.

You too nice. Enjoy your day.
Jesse

[Jammu]

Thanks Kerri for all the input. This is a great start for us to investigate various options.

regards

[Jammu]

This is laughable.Since when being "nice" or professional and respectful become a bad thing? 

 I just hope these kind of responses on this forum are an exception and not the norm. 

I didn't realize asking questions on this forum had anything to do with "$$$".

Frankly, I was warned about something like this by others and they recommended just going the native apps way, but I continue to believe in phonegap and the concept.

Thank you again Kerry for spending previous time in giving your feedback. It has been extremely valuable.

regards.

[Steve Sobol - Lobos Studios]

Hold on just a second, Jammu.

You were told, quite politely, by Jesse, that PhoneGap and Apache Cordova do not work the way you want them to work.

You then argued "but it works on iOS".

I don't know exactly what you did, but I'm telling you now, politely, that no, it doesn't work that way with PG on iOS or ANY of the supported platforms. I'm not sure why you think it works that way on iOS. The platform is designed to create hybrid apps where the actual HTML/CSS/JS content is pulled from local files. There are ways to pull down content *after* the app launches, of course, and they are much the same as the methods used to

It seems that Jesse got upset because you pushed to be told you could do things the way you want to, and frankly, I don't blame him for being upset. His initial response was not rude at all; blunt and to the point, for sure, but not rude. Jesse is a blunt-and-to-the-point kind of guy. But he also contributes a LOT of help and a LOT of useful information.

I'm pretty sure he'd have been fine if you hadn't argued.

I will remind you again (because I believe Jesse already said this) that we all have jobs, and we do like to help whenever possible, but participation in this forum is on a volunteer basis.

Kerry addressed your questions about live app updates.

Point of order: you talk about being professional; when you are researching a new (to you) technology, talking to people who use it day in and day out, and they say "You can't do X", and you insist "Oh yes I can, I'm already doing it", that isn't professional *or* nice. Would I have responded like Jesse did? Maybe... maybe not. Would I have been happy with your answer? No. And given my personality, I'm not sure I wouldn't have snapped at you either.

Just my two cents, adjusted for inflation. I mean this to be constructive criticism - and I hope you will take it that way.

Jammu wrote:

--
-- You received this message because you are subscribed to the Google
Groups "phonegap" group.
To post to this group, send email to phon...@googlegroups.com
To unsubscribe from this group, send email to
phonegap+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/phonegap?hl=en?hl=en
 
For more info on PhoneGap or to download the code go to www.phonegap.com
---
You received this message because you are subscribed to the Google Groups "phonegap" group.
To unsubscribe from this group and stop receiving emails from it, send an email to phonegap+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Lobos Studios - Website and Mobile App Design & Development; IT Support; Computer Maintenance
Toll Free  877.919.4WEB - Apple Valley 760.684.8859 - Los Angeles 310.945.2410 - Cleveland 216.242.4010
www.LobosStudios.com * www.facebook.com/LobosStudios * @LobosStudios

[Steve Sobol - Lobos Studios]

"much the same as the methods used to pull content in native apps and on websites", sorry.

[Siphiwe Gwebu]

@Jammu were you able to get past this problem by any chance? I have the same problem ("deviceready has not fired after 5 seconds" and "Channel not fired: onCordovaInfoReady"). I'm running this in an Ionic app (not loading a web app off a server). I'm battling to find any pointers to what might be going on.

Thanks