Open joejoe2016 opened 6 years ago
I've been investigating this topic online and now think that it's probably less work to implement eg. #211 for android and ios separately than moving/rewriting to and app framework like xamarin. ;-)
Yes, the one I'm most interested in right now is Flutter https://flutter.io/
I've tried using some of the web-based ones in the past like Ionic and it just wasn't worth it.
I've been using Xamarin in a basic way, I had a quick view at flutter.io - it also looks promising, but in order to build an iOS-app it also necessary with flutter.io to have a Mac. But I think it would be necessary to discuss in general if the effort should be taken to switch to an app framework and therefore abandon the existing apps (altough it seems that with flutter.io it is possible to reuse code) or go on with the existing apps.
As github issues are probably not the best place to discuss such general stuff I was about to create a mailing list but first wanted to ask if you agree or if there's one I don't know of.
You might be able to work your way into it “backwards” with something like Expo if you start building some of your views in React Native and use ExpoKit to integrate certain cross platform features (you’d start out as an “ejected” app). I’d probably recommend holding off unless you have a major view/scene rewrite or new feature that would justify the framework integration investment.
Some info about Expo:
thanks for the links, I'll check them. Although I'm not sure whether it's worth to do a framework change (the existing apps are quite good and perhaps effort should be put in something else like getting more users and translations)
I've been investigating about the topic and found eg. these links https://blog.novoda.com/react-native-flutter-xamarin-a-comparison/ https://visualstudiomagazine.com/articles/2018/03/01/flutter-xamarin.aspx
It would be probably quite an effort to start again from scratch but I think it's worth using to an app framework. My favorite is (as chris) flutter. For me that has the big advantage that for developing the iOS-app no Mac is necessary. Building can be done via Travis and testing in simulator via browserstack. https://medium.com/flutter-io/test-flutter-apps-on-travis-3fd5142ecd8c https://medium.com/@yegorj/building-flutter-apks-and-ipas-on-travis-98d84d8e9b4
Have you @chrislim, done already a ceseless-demo with flutter? Perhaps you can upload it to a repo and give me write access so that I can also work on it. Or if not - can you create an empty repo and give me write access to make some first steps and try it out?
Curious about what you think about the topic.
@joejoe2016 sorry I missed your comment, but I saw that you just created a flutter project! I didn't have one yet so that's great. Your point about being able to development without needing a Mac is a good point.
I also recently stumbled on this article that impressed me with what could be possible using weed/react native: https://blog.usejournal.com/bindingx-going-native-without-going-native-5e742995ea93 but there is still something about flutters approach that seems elegant.
weed/react native also might be a good alternative - perhaps I'll give it a try later on. Yes, I started a flutter project to try out the framework and to evaluate if it might be reasonable to change to flutter.
I investigated a bit about flutter and see the following pros and cons for ceaseless: Flutter would have the advantage of using the same code base for android and iOS. Although this means quick some effort if we decided to change the existing apps to flutter. An alternative would be to integrate flutter into the existing apps for new features we would like to implement (please see here and here for some examples. One feature we could integrate like this is the feature of syncing between devices and backuping journals. There's a demo app called
(This is the second part of my previous post). FriendlyChat that shows how to integrate firebase auth and firebase database into an app for syncing. see also this manual for further explanation. So with this we could set up login and backup features for ceaseless. Although I think we still need to maintain the default database locally and not directly sync to eg. firebase because of GPDR
Another point to discuss would be the type of the internal architecture. I saw that the native android app uses REALM (I suppose the iOS app also does) According to this post realm is not yet supported by flutter. So we could either wait until this is supported or change to another database like sqflite but then people would loose all their data like journals if they update via play store from the old native app to the flutter app which would be a major drawback. Alternatively we could create a new name for the flutter app and people could switch to the new one - but then they would also loose their data. After all this analysis I think that for now we should go on using the native code.
@chrislim and the others? What do you think?
Hi, this is not an issue but kind of a wider discussion. When I read through the open issues I found issue #211 (User request: Ability to write prayer on other device (i.e. computer, tablet) and add it to ceaseless enhancement ). If it was decided to implement this (or any other feature) this would need to be implemented in the iOS-app and again in the android app (and if one day available also on a Windows Phone app, I read about this on the homepage). So I came up with the question if it wouldn't be better to develop Ceaseless instead with an App-Framework like Xamarin, PhoneGap, Framework 7, Quasar etc. only once (we'll I mean the core only once and UI for each platform). I'm aware that this would be quite an effort as quite a lot of code would need a rewrite but I'm just curious - have you been thinking about this option?