That’s how I got started. ReactNative is easier than Native iOS if you’re a web dev. And the <View>
and <Text>
components don’t feel like HTML so it doesn’t feel dirty mixing JS and HTML. Egghead has a really nice video on it too.
Yes, that sounds interesting. Yet I have to say that native iOS is quite easy since Apple introduced Swift. I learned it some weeks ago and I have to say that I indeed miss many of the Swift features in JavaScript. For me, it would be perfect if Swift was also a language that could be used for my Meteor application. Maybe this will be possible in the future, since Apple opened Swift as Open Source. And even more than that I would love to program Android apps using Swift, as I really dislike Java due to its complexity and over-sophistication.
[quote=“waldgeist, post:9, topic:8891, full:true”]I would love to program Android apps using Swift, as I really dislike Java due to its complexity and over-sophistication.
[/quote]
If you like Swift for iOS and hate Java for Android, you should consider using Groovy for Android. Groovy is one of the modern languages that Swift seems to be inspired by. These links should help you explore further on this:
- http://melix.github.io/blog/2014/06/grooid.html
- https://www.youtube.com/watch?v=U_p2L47gvgk
- http://www.codebulb.ch/2015/06/painless-android-development-with-groovy-and-swissknife-part-1.html
I’ve not tried it personally but have been using Groovy for many years on the server side, rarely had to use Java since then. Groovy support for android is quite new though, so make sure you’ve done your mandatory checks.
Groovy sounds interesting. Yet, I have to admit that my capacities for using multiple languages in parallel are limited - this confuses me too much. If Groovy was a lingua franca for everything (Meteor, iOS, Android), I would be very happy.
React Native support would be awesome! This one is on my list. I’m not sure if anyone is working on this though.
For full Meteor client support see the 12th comment on this post:
Meteor + Webpack: ES6 modules, hot-code-patching, fixes load order & more - #12 by SkinnyGeek1010
Basically we just need to polyfill some browser events and all should work like it does in the browser. Using webpack it’s fairly trivial to send all the meteor core + packaged to the app, then transfer the app code on file-change for development.
There’s already work started to allows ReactNative to request new app bundles on demand so that should be cooked in a little bit.
Since react-native is now out for android too(open-sourced ) this week. Was wondering if there is a way we can think of packaging react-native app with meteor. I see meteor apps are generally packaged as cordova only. So, i do not see a way, but i am way way behind in understanding meteor stuff off late.
hello
Any news on this topic ?
Best
jeangui
Spencer Carli wrote a post in the Differential blog about his experience with React Native and Meteor. Definitely worth the read if you are interested in React Native.
Link: http://blog.differential.com/meteor-react-native-learning-from-experience/
Thanks for the link.
I gonna have a look.
I would love to see real support for react native as well!
Waking up an old thread. Any news on RN bundling? Now that RN has pretty complete support for Android too.
No integration yet. You can still use the low level DDP methods for realtime pub/sub.
Meteor-GraphQL and Lokka are also an option if you want to go that route. Currently no realtime support as the spec isn’t finished yet. I’m going to slowly integrate this into my own RN app to replace the AJAX calls.
At this point I don’t see why it’s so important for there to be tight Meteor integration unless you want Tracker and minimongo so badly. Just use the DDP client Npm package and be done with it. There’s a whole bunch of great libraries for handling data and optimistic updates already. There should be nothing stopping you from building an RN app that communicates with Meteor.
Isn’t the dynamic updating the biggest advantage?
@martijnwalraven Would it be possible to use the new download mechanism to grab the latest react native bundle and serve it locally?
@batist: We might be able to reuse parts of the new download mechanism for React Native, but right now it is implemented as a Cordova plugin and tied to the needs of web apps (it serves files through an embedded HTTP server / request interception mechanism).
The main advantages of the plugin are incremental updates and tight integration with our build tool, but those seem less important with React Native and might actually be a disadvantage (having to use our build tool would mean you couldn’t take advantage of React Native’s packager
or react-native-webpack-server
).
Products like AppHub will allow you to push JS code to the client without re-uploading to the app stores. Like Cordova, if any native code is changed then re-uploading to the appstore is required.
Now that GraphQL is the future delivery system for data, integrating the rest of the browser meteor JS code is a pretty low priority since node-ddp-client, ddp-login, and vanilla graphql handle all you need. I think someone also open-sourced a wrapper for node-ddp-client that gives you a meteor.js like API.
If you need minimongo with a local collection, Pete hunt open-sourced one that works with RN.
Would it be to much to ask you to elaborate on “GraphQL being the future delivery” and how does that impact meteor js via react native
Sure! I think that’ll help solidify the opinions bouncing around my head too
TL;DR If you boil it down it comes down to the problem of old native app versions that are not upgraded that break as the backend changes due to a different response or query. GraphQL solves this problem very elegantly.
MDG is working on a reactive layer for GraphQL called Apollo. For more complicated apps this will be the preferred approach because of it’s flexibility and scalability.
Pub/Sub and Livequery will still continue to work in the browser but getting that to work in React Native as well will take a lot of work for little for very little benefit (basically people who have already learned livequery won’t have to relearn GraphQL).
This nice NPM package react-native-meteor fills the gap between Meteor in the browser and node-ddp-client (which is a bit verbose honestly). It basically gives you the ability to login, call methods, and subscribe to reactive-data.
Ok back to GraphQL. So today in React Native if you want to get non-reactive data you can:
- use AJAX calls to a Meteor serverside router
- call
Meteor.call
with a DDP client like react-native-meteor - use Kadira’s GraphQL Meteor package (includes Meteor auth)
In this case (non-reactive data fetching), AJAX is backend independent but doesn’t offer Meteor auth integration and suffers from version constraints from older native apps. Meteor.call also has this version constraint issue.
The GraphQL package has built in Meteor auth support and doesn’t suffer from the old app version problems (due to deprecation of fields). You can have clients many versions behind and still work perfectly. It was first conceived to fix this problem with mobile APIs at Facebook and then moved to other apps later. This is the main reason why I think it’s a no-brainer to choose for mobile apps.
However, there is an elephant in the room. Reactivity. If your app needs reactive data then you have a few options. You can long-poll the GraphQL request every X secs/mins to refresh data and then eventually swap out any minimal changes when Apollo is done.
If you really need reactivity that is so frequent that long polling is untenable then you can use the previously mentioned react-native-meteor module to subscribe to data and then cache the data.
Regardless of if it’s reactive or not, any one of those methods will have a response callback with data that needs to get inserted somewhere to update the view. It could be Reacts own setState
, Redux, minimongo-cache, etc… This is process is very very similar to making an AJAX request and storing in a local minimongo collection with vanilla Meteor.
Hope this helps!