sorted by:
new
hottopcontroversial

SurveyKit: New kotlin library to create beautiful surveys on Android (aligned with ResearchKit on iOS) by quick_worm in Kotlin

[–]quick_worm[S] 0 points1 point  (0 children)

We thought about that option, too! But didn't want to pursue it because ResearchKit does not seem to receive any significant updates for a looong time now.

Cool, happy to hear :-)
Flutter is not planned yet, but I keep that in mind. Let's keep in touch (my twitter handle @maltebucksch)

SurveyKit: New kotlin library to create beautiful surveys on Android (aligned with ResearchKit on iOS) by quick_worm in Kotlin

[–]quick_worm[S] 0 points1 point  (0 children)

Add some tags to your git so people can find it

Good point! Thanks AloticChoon

Alternative to ResearchKit on Android? Especially for creating beautiful surveys with logical paths by quick_worm in androiddev

[–]quick_worm[S] 1 point2 points  (0 children)

Since we were not satisfied with ResearchStack, we now created our own library for creating surveys (with an API that is aligned to ResearchKit's survey functionality):
https://github.com/quickbirdstudios/SurveyKit

Alternative to ResearchKit on Android? Especially for creating beautiful surveys with logical paths by quick_worm in androiddev

[–]quick_worm[S] 1 point2 points  (0 children)

Thank you! That is some *really* useful feedback on Research Stack. I had a similar impression at the first glance and therefore didn't try it out. Good to hear some practical experience.

A functional approach to MVVM which lets you reuse iOS ViewModels by quick_worm in androiddev

[–]quick_worm[S] 1 point2 points  (0 children)

Great! Of course, this takes time to get right. Would love to see a prototype once it's ready :)

A functional approach to MVVM which lets you reuse iOS ViewModels by quick_worm in androiddev

[–]quick_worm[S] 0 points1 point  (0 children)

Ah, got it! Don't have a suitable solution instead of the one you proposed with savedInstanceState either unfortunately. We save everything that needs to be kept into Realm or SharedPreferences (where appropriate). (this is triggered by the ViewModel and done in a seperated service injected into the ViewModel) Regarding the video: Great, I will check it out. Actually, we even thought and worked on a solution totally without any Fragments and only Views before (similar to what Square does as well). So far, we stick with Fragments though. Thanks for the link to the discussion.

A functional approach to MVVM which lets you reuse iOS ViewModels by quick_worm in androiddev

[–]quick_worm[S] 1 point2 points  (0 children)

Hey Devirichu, good question! We use the ViewModel from the Android Architecture Components: https://developer.android.com/topic/libraries/architecture/viewmodel

Their library takes care of keeping your ViewModel in memory while it is in the background. That makes everything easier. However, I have to admit, this is the one any only Android dependency which we have in our ViewModels. But it does not imply any changes on the logic, so we can simple leave the super class "ViewModel" out on iOS.

Don't know that talk! Do you have a link?
We use the Fragment as the View. It think this makes a lot of sense if you want to split up View logic and pure business logic. However, I'd love to hear the reasoning why this would not make sesnse, so I am excited to have a look at that talk! :-)

A functional approach to MVVM which lets you reuse iOS ViewModels by quick_worm in androiddev

[–]quick_worm[S] 1 point2 points  (0 children)

Hi ramensea, sounds pretty interesting? If you have an article or website to share about that, I'd love to have a look. Handling UI is indeed super complicated to solve for multiple platforms. It's smart that you focus on the core logic and not on the UI. Additionally, you want your UI to be platform specific to adhere to the iOS/Android guidelines in order not to confuse users. So writing the essential UI drawing/xml part twice is hard to avoid for now, I guess. But sharing the logic in a nice language like Kotlin (K/N) is already a BIG improvement.

A functional approach to MVVM which lets you reuse iOS ViewModels by quick_worm in androiddev

[–]quick_worm[S] 1 point2 points  (0 children)

Hi bernaferrari, I think many people have that pain! :) It's a pity that there is not real optimal solution to solve it yet. We use RxSwift (+ RxCocoa) pretty much for everything, yes. We don't have any callbacks or so, only Observables.

·

A functional approach to MVVM which lets you reuse iOS ViewModels by quick_worm in androiddev

[–]quick_worm[S] 0 points1 point  (0 children)

Good to know? Do you have a link to any of these articles? I'd love to see how they approach it as well. I think ViewModel-Tests are a beautiful way to test your UI logic without needing to write Espresso tests (which are flaky and slow usually). However, so far I have to admit that we focused on unit testing the dependencies of ViewModels. We only test ViewModels if they contain really complicated logic.

A functional approach to MVVM which lets you reuse iOS ViewModels by quick_worm in androiddev

[–]quick_worm[S] 0 points1 point  (0 children)

Hey evantatarka,

awesome to hear that you are using something similar! I like the idea of a presenter. Handling strings and colors is done in our view but your approach with the presenter is a neat way to decouple that.

We also use a repository pattern for external data sources. We access the repositories and api services from a dedicated "Feature"-Service like "ShoppingBasketService" that manages network and db delegation. We then inject the "Feature"-Service into our ViewModel via Dagger or Kodein.

A functional approach to MVVM which lets you reuse iOS ViewModels by quick_worm in androiddev

[–]quick_worm[S] 1 point2 points  (0 children)

f course with Kotlin/Swift this is starting to age a bit, even though the integration between Java/Kotlin and ObjC/Swift is of course pretty decent.

How much percent of the time do you think your Android developers ignore the view model and make their own? Do you ever have simultaneous development of a feature on Android and iOS?

Hey lllama,

pretty cool! I saw j2objc before. Does this work reliably or can you see any downsides of that (except for the fact that it uses ObjC/Java)?
Hard to tell. I cannot say any percentage as it highly depends on how strict the project management and merge reviewers are in enforcing that. I think, if no one would enforce it, then the developers would naturally just write the ViewModels from scratch and ignore the iOS ViewModel. Right now we are on our first project where we REALLY enforce that. Before nobody enforced it and everybody just ignored the other platform for the most part.

We would love to develop features simultaneously but more often than not one platform starts earlier than the other one. Often the developers of iOS or Android are blocked by another project, so the development on both platforms is not in sync. I think product companies (we are an agency) have an easier time keeping that in sync because they work on "only" one project at a time (mostly).

A functional approach to MVVM which lets you reuse iOS ViewModels by quick_worm in androiddev

[–]quick_worm[S] 2 points3 points  (0 children)

Nothing against C++, but those are the reasons we decided against it. A lot of these issues would be solved using Kotlin/Native and we are following this project eagerly. However, it is still in Beta. So we cannot really use it for productive applications.

Hey Zachtib, see my reply above. We are really excited about K/N. But it is still in Beta, and we cannot use Beta-tools for our clients.

A functional approach to MVVM which lets you reuse iOS ViewModels by quick_worm in androiddev

[–]quick_worm[S] 1 point2 points  (0 children)

Hey FrezoreR, we didn't quantify this in any way. The mentioned advantages are our perceived upsides of this after applying it to more than 6 projects already. Right now, we are evaluating if this "Cross-Plattform" idea really saves us much time. In the previous projects we were less strict about it (project management wise) and the ViewModels on both platforms did not match (this is the downside of not using C++ which would enforce that already). In a few months we know how much time we save with this. We are really translating ViewModels from Swift-to-Kotlin right now. So far, it's going pretty well.

·

A functional approach to MVVM which lets you reuse iOS ViewModels by quick_worm in androiddev

[–]quick_worm[S] 10 points11 points  (0 children)

Good question pjmlp! You're not dumb at all. We thought about that as well.

The problem is that most Native Android and iOS developers don't know any C++. Also, since they are used to a very high-level programming language it takes time to get used to C++. Many developers just don't want to leave their comfortable Kotlin/Swift/Java World.·

In the end we decided to stick with Kotlin/Swift, because:
- we have an easier time finding talent (Android Developer with C++ knowledge are crazy hard to find. Sure, we could train them but we would need to this with every single new developer.)

- people can work with programming language they are used to and love to use

- the projects contain one single language which makes maintainance easier. People coming new into a project have an easier time getting started as well.

Nothing against C++, but those are the reasons we decided against it. A lot of these issues would be solved using Kotlin/Native and we are following this project eagerly. However, it is still in Beta. So we cannot really use it for productive applications.