1. What about the UI elements of Android and iOS? We still have to buy something like Kendo UI to work with Phonegap on Android/iOS.
I believe it will be better strategy for Meteor team to work and integrate their server with native Android/iOS app instead of Phonegap.
2. Also it is difficult to understand how Latency compensation will work. Does local in-memory copy of database work with Sqlite or does meteor install mini-mango on Android/iOS?
3. The author in the blog has written that they have improved the login by redirect based oAuth login in WebView. Webviews are surly not optimized for mobile devices and gives horrible user experience. If webviews would have worked there was no need for facebook to rebuild the HTML app.
Meteor team is far from providing a unified platform which can be used for Web and Android and iOS. It is good only for web.
From what I have seen, if you write PhoneGap apps, you simply don't care about UX or performances.
It does not mean that it is useless, there are cases where UX & perfs do not matter, like corporate apps that will only be used by employees.
The meteor app gets packaged and deployed to a mobile device. The blog references code updates from "a" server. I'm confused- are you still running a server? How does the packaged app know where to pull these updates from? Does the client share persistent data with this server?
Meteor dev here. When you bundle a Meteor app, you specify a server which will handle updates (and server logic). You can push new versions of the application to this server, and all mobile devices will automatically be notified of the update and download the new code.
So the deployment process is two-part:
1. Bundle a mobile application with JS/HTML/CSS which talks to a server at foo.meteor.com
2. Run a server at foo.meteor.com. Whenever you push a new version of the application to the server, the mobile devices will download the new JS/HTML/CSS and refresh to run the new code.
The server and mobile device "share persistent data" in the sense that the mobile device will eventually contain the same client code as the server.
Latency compensation works as usual, meaning that actions are immediately carried out on a local in-memory copy of the database, and then replicated to the server. There is no offline caching at the moment, but it's on our roadmap and there are some community solutions that you could try out.
In my app I close the connection when the app is backgrounded, and reconnect when the user resumes using the app. Meteor automatically deals with any changes that occurred while the connection was offline. In short, battery life has not been an issue.
The OS doesn't power down the antenna while there are open network connections. Did your tests wait long enough to turn off the antenna, was the test environment clean (i.e., nothing else using the network on the device, including your tests)?
I have a Meteor app in the app store (built before this official support) and had no trouble with the approval process. The ability to update over the air is quite nice. The only time you have to resubmit to apple is when you update the objective c part of the phonegap project.
Pretty surprised they are at 0.9 now. I worked with Meteor last year in June but we soon gave up using it on a project. I wonder what has changed since then, if it's actually scalable and stable to use.
I'm also curious as to how the mobile apps will run on older Android phones.
For real time I thought about using Firebase which seemed a lot more easier and reliable than Meteor, but now that they are closer to 1.0.0 I am keen to have a look at Meteor.js again.
We used it to build an enterprise app for the fishing industry. Real-time was the key feature. 4mb downloads on simple table view with real time edits by multiple users. At the time we were reading Discover Metoer book by Sascha Greif and trying to figure things out using Atmosphere packages. Derby.js was another consideration but since Meteor was more popular we chose it.
Anyways looking back, we used so many exotic new tech stacks to do really simple applications which cost more and didn't really give other edge. I quit using Javascript on the server side and started to pick up Python.
I don't plan on going back to Javasscript from Python but Python really lacks a real-time framework like Meteor and still Python to Javascript compiler has not really picked up momentum from what I can see.
I think if Python does not bring itself to the browser soon it could mean trouble for future relevance. The fact that we have MEAN stacks and such pisses me off. You don't need that shit to write your god damn Facebook clone, just use Python or PHP. OR the famous writing a REST api before you write your website is the even crazier one. It's not too late to abstract out a restful backend from your web app until you decide to write blackberry, android, iphone apps.
I believe it will be better strategy for Meteor team to work and integrate their server with native Android/iOS app instead of Phonegap.
2. Also it is difficult to understand how Latency compensation will work. Does local in-memory copy of database work with Sqlite or does meteor install mini-mango on Android/iOS?
3. The author in the blog has written that they have improved the login by redirect based oAuth login in WebView. Webviews are surly not optimized for mobile devices and gives horrible user experience. If webviews would have worked there was no need for facebook to rebuild the HTML app.
Meteor team is far from providing a unified platform which can be used for Web and Android and iOS. It is good only for web.