61–70 of 74 posts
Earlier quoted context omitted.
Of course, this advantage is more than outweighed by having to use JavaScript in the first place.
Considering all of the languages that can transpile to JS, I wouldn't say that's an issue. Now the bugs and shortcomings of CSS, that's certainly a knock against hybrid apps :)
I once worked for Pyxis Mobile (now Verivo Inc.) which touted a platform which would provide you with native iOS, Android, and BlackBerry (years ago..) apps, which would build themselves at run time based on a database/app meta data. This allowed apps to completely change themselves without a resubmission, while being in-line with Apple's guidelines, and technically be purely native. Between lazy loading and the fact…
Have you ever done A/B testing? That's the real value if you want to actually measure things and improve them. Maybe doing so can even minimize spectacular bugs when you push. And how would you accomplish this A/B iteration with weekly pushes to everyone?
Earlier quoted context omitted.
Have you ever done A/B testing? That's the real value if you want to actually measure things and improve them. Maybe doing so can even minimize spectacular bugs when you push. And how would you accomplish this A/B iteration with weekly pushes to everyone?
You could code both views and show one or the other based on a server-side flag.
Earlier quoted context omitted.
Considering all of the languages that can transpile to JS, I wouldn't say that's an issue. Now the bugs and shortcomings of CSS, that's certainly a knock against hybrid apps :)
Wasting CPU time on a mobile device by 'transpiling' is pie in the sky webdev nonsense.
Or can I work around the standard way Appcelerator works for example by making more Javascript code available through a webkit Ti.UI.Webview or something?
1. script must be downloaded only within UIWebView. 2. script must be excuted only within UIWebView.
Not sure why #1 is important to Apple but #2 makes perfect sense. I'm assuming Meteor is downloading scripts then passing them as 'data' to native-side to be cached somewhere until it needs to be injected back into UIWebView for execution.
Unless I'm mistaken, two primary restrictions are: 1. script must be downloaded only within UIWebView. 2. script must be excuted only within UIWebView. Not sure why #1 is important to Apple but #2 makes perfect sense. I'm assuming Meteor is downloading scripts then passing them as 'data' to native-side to be cached somewhere until it needs to be injected back into UIWebView for execution.
Earlier quoted context omitted.
You could code both views and show one or the other based on a server-side flag.
And that is rudimentary "code push" isn't it?
Unless I'm mistaken, two primary restrictions are: 1. script must be downloaded only within UIWebView. 2. script must be excuted only within UIWebView. Not sure why #1 is important to Apple but #2 makes perfect sense. I'm assuming Meteor is downloading scripts then passing them as 'data' to native-side to be cached somewhere until it needs to be injected back into UIWebView for execution.