I have an existing iOS app and I'm trying out KMM. Ideally, when launched, the app would be available both for Android and iOS, but I'd like for existing iOS users not to lose their current content.
I started building a MigratorService in iosMain, as all it's going to be doing is dealing with platform-specific models, but then I didn't have a way to call it from commonMain. So I either:
Move all the code I've done in iosMain to commonMain. Although there is the potential risk of exposing old iOS related code to Android, in reality this would never happen since the migration only happens for iOS.
Create an expect MigratorService in commonMain, with the actual implementation being on iosMain. But this approach implies also adding a complete no-op version of MigratorService in androidMain. Which is exposing an API that doesn't really do what is expected.
Which one would be considered the best practice in KMM and why? Or is there another alternative to tackle these situations?
Cheers
Related
Background:
I need to start working on project which we are hoping to maintain it for long time (Basically reusable components which will be reused in multiple projects). I was exploring the Reactive Programming and the benefits Reactive Programming brings to the table is way to high to ignore it.
I started exploring various FRP frameworks available and RxSwift, ReactiveCocoa were few such examples. But looking at the community support and swift implementation, RxSwift was obviously the choice.
Now RxSwift4 came with some breaking changes as RxSwift3 wasn't compatible with Swift4. Now community did a great job to bridge the changes smooth, though but things like DelegateProxy implemented in RxSwift3 started breaking in RxSwift4. So for those who used RxSwift3 it wasn't just a pod update but involved loads of changes as well. On following the RxSwift Git hub issue realized that its because of Swift4 changes which lead to this break.
Question:
Now its a very common risk that we take on using all third party frameworks, but with most of the frameworks I used, if broke they would have break a feature or two in app but if I write a complete app in RxSwift and future updates break, finding a replaceable library and replacing it would be a enormous job.
Here is why?
For example, if you use Alamofire, usually you will have your own Network layer in app which would expose certain API to app and app quite frankly wont worry about the library used under the hood. So replacing it is quite a easy task. But with RxSwift all asynchronous tools like delegates, blocks,notifications are already wrapped in RxSwift components like Observables,Subjects,Units etc to which we cant write a wrapper of our own and if Current RxSwift version breaks in future update we will be left with no other solution than to literally fix them one by one, as replacing library would mean complete re writing of project.
I know its a kind of opinion based question, but the problem is there is no much guiding opinion on web for the same. I would really appreciate, if somebody who used FRP frameworks in their project post the best practice to use them so that dependency on framework will be minimal and allow us to shift to new FRP framework easily in future.
EDIT:
The mention of Alamofire above is just to show how easy it is to wrap other frameworks that we use in our app only and has nothing to do with RxSwift in itself. So please don't get carried away by that :)
My short opinion-based answer is that it is safe enough starting from Swift3 because backwards-compatibility is guaranteed starting from Swift3 onwards. I use RxSwift and a bunch of derived frameworks (RxCoreData, RxCloudKit, RxGesture, RxCoreMotion and RaspSwift) extensively for about a year now, never encountered anything particularly troublesome. But then again, you mentioned some frameworks which I did not use that gave compatibility troubles. So apparently there might be unpleasant surprises, which are usually fixed quick enough by the open-source community.
I am planning to build an iOS app with react native and I am super excited to do so.
Unfortunately the deadline is quite short, so I am considering to use an approach like this, which hosts the app bundle in the cloud for the production build of the application.
This may be beneficial, as an api will be build for the app and I could simply change the code of the deployed app if the api behaves otherwise than previously assumed.
As this seems like a good idea on first thought and I am quite sure it is a good idea in terms of testing and continuous delivery I am not sure if this works out in production and if the application will be accapted by apple.
So my question is if such an application would be approved by apple and if this kind of structure provides any problems on the users devices.
Yes, this tends to be good idea. Usually, application stores a lot of data (authentication, user data and so on) on it's own servers.
How to go about designing a multi-platform app that offers In-App-Purchase?
I'm working with JUCE (Win/OSX/Lin/iOS/Andr).
I know that iOS allows IAP. So I'm guessing OSX also does. I would suspect Windows and Android also provide something similar. I doubt Linux provides anything as it is decentralised by nature.
So maybe I would have to write 4 separate IAP modules, and maintain 4 separate stores. Yuck! I don't want to do that. I recoil from duplication.
Is there any way to unify IAP across these different platforms?
The ideal solution would be single store to maintain, and a single C++ API to access it.
But is this even possible? I think Apple explicitly forbid any kind of store/monetising outside of their system. But http://soom.la/ seems to provide some work around for Unity3D.
The api will be same, but the platform specific functionality has to be separate. This way you have one repository and for a given platform build, pull the required code. Here is an example "Upload XML data to MySQL or NoSQL"
I have a whole project developed under iOS which is a sales channel / ecommerce app which is a white branded product.
It mainly relies on a webapp but the native container handles a lot of features (session management, additional services, register to push notification) which is not only intented to make distribution on AppStore possible.
Thus, lot of code within the application delegate, use of several libraries through CocoaPods, etc.
Now, some of our customers whould love to integrate this ecommerce in their existing native apps, for instance, as a tab in a UITabBarController.
What is the best approach to do so ? Considering notably that both AppDelegate must be called, etc?
Thanks
I would advice to refactor your code and extract as much as possible to add it into your own Framework if you really want to keep it clean and have a good way of providing support to your customers. (refactor in a way so that it is easy to use for external projects, for example providing delegates/blocks in a matter that is straight-forward to implement).
A great starting point for learning how to create (Objective-C) iOS Frameworks can be found at https://github.com/jverkoey/iOS-Framework.
Any dependency (external library) you use for building the Framework will become a dependency for the project that will use your framework, unless you can add the source in your Framework.
Also take a look into providing documentation using Doxygen, AppleDoc, etc ;-)
Though I am a programmer, I have never written for any Apple device. As such, my iOS-specific knowledge and familiarity with their API is nearly non-existent so please bear with me.
I would like to create an action from the lock screen (swipe, double tap clock, whatever) that would unlock and immediately open the App Switcher (I am not interested in extensions ala SwitcherPlus or the like). I guess this means writing a small script, and I could use some help concerning the API and other basics (the core features, shouldn't need any fringe stuff). While I am willing to get into the nitty gritty if need be, I am open to other solutions. Even something as high-level as chaining several Activator responses together would be fine.
I see Ruby under Cydia/Scripting (Telesphoreo). Though I'd slightly prefer Python or even Bash, being that my purposes are fairly minor Ruby would be just fine. I would rather not use Objective-C. While my original goal is the behavior described above, I can see myself wanting to do similar things in the future so some tips towards general know-how would be much appreciated.
If it is not clear, this a purely personal project. I am not at all concerned with packaging, sharing, backwards compatibility, commercial appeal, etc
PS - I have, until this point, set my Cydia viewing to "hacker" but not "dev". Does this endeavor indicate that I should up it to dev? The term seems a little generous, but if it opens up packages that I will need...
EDIT: I use an iPhone 4S, iOS 5.0.1
I don't think that this is possible in any scripting language. For one reason: You'll need to do code injection to achieve these goals (MobileSubstrate).
1) If you want to detect user interaction, you'll have to add ways to detect it or hook implementations which are already there. Even if you just wanna use Activator, you'll still have to develop a binary to register itself with Activator -> objC
2) There is no known way (at least to me) to interact with SpringBoard via scripts the way you want. So you'll have to make a binary which would execute the opening of the switcher.
I hope someone will have a better answer for you, but I'm very very sure that you won't get around using C/objC
There is a tool called http://www.cycript.org/ which is a bridge between JavaScript and objC, but I have never seen it being used for more than investigating.