App 30 – Preparing Today’s Android App for Tomorrow’s Cross-Platform Version

0
2

Bill W:

I realized that I hadn’t been thinking ahead to gig drivers that were using iPhones. In setting up the programming envionment for ShelfViews app, I had conciousoly chose a cross-platform dvelopment strategy using a standard called “flutter”. but for this project, somehow I had started it as a native android project. Grrr.

Chad G:

The thirtieth step was mostly invisible to the user, but it was about protecting the future of the project.

The app was being built natively for Android, yet we were already considering an eventual cross-platform version. S2-08 therefore asked for architecture that could later migrate toward Kotlin Multiplatform without forcing us to rewrite every piece of business logic.

The practical approach was not ‘convert everything now.’ Android-specific pieces such as screen capture, services and permissions would remain Android-specific. But domain models, repositories, rules and other platform-neutral logic should avoid unnecessary dependence on Android classes where a cleaner boundary was possible.

That is a fitting thirtieth article because it shows how far the project had moved. The first prompt merely defined a companion utility. By this point we were thinking about evidence preservation, storage, research, physical controls, social features, diagnostics and the possibility of carrying the same core ideas onto another platform – while still trying to build one brick at a time.

@@@

LEAVE A REPLY

Please enter your comment!
Please enter your name here