I've been attempting to keep up on new technologies that enable developing applications which can be easily adapted to mobile or web based deployments. Cross platform technologies that support Android, IOS and the Web, with a small percentage of modifications required for each platform, were what sparked my interest.

The first two apps that I published were developed using platforms having there roots in web based technologies.  They were written in jQuery Mobile and deployed using the cordova.apache.org/ platform.  One of the first mobile based platform deployment technologies supporting HTML applications natively on mobile.

The first app didn't require full stack development as it just was a location based app that ran on the phone using the BING maps API, you can see more about that in my older blog posts..  The second app was full stack and used MongoDB in the backend with the API's deployed as Python WSGI servers on the Redhat Openshift platform.  Over the years some work was needed to keep the backend up and running but very little was done to modify the HTML/JS frontend UI.  This was originally an app built with jQuery Mobile and published in the Google Play store using the Cordova platform to wrap it as a mobile application.   The backend had to be supported as the Openshift platform became too expensive for an application that supported one vendor for free.  The first move was actually a need to upgrade it form the early Openshift platform to the Version 2 platform.  When version two became price prohibitive the backend was temporarily moved to PythonAnywhere and ran fairly well there as it's usage was not demanding.  The largest base of users it ever had was about 2000.  In the last iteration of backend work I learned how to deploy the python code as Lambda functions (Serverless).  The backend was ported to use the following AWS technologies: Amplify, API Gateway and Lambda.  It's still active today as a web app which required no modification to move it to a web site since it used HTML & JS.  You can read more about that on a few of my earlier posts.

Over the past few years I keept aware of what was happening in the world of crossplatfom tech but never really buckled down and did much of a deep dive.  You will see a few blog entries about FlutterFlow which I came across about two years ago.  I just tinkered with it and wrote a very rudimentary version of a frontend that could use my HTTP API's to pull data from a MongoDB Atlas backend.  I never really went too far with it even though I did purchase a license two years in a row, so, you can say I'm an investor in your effort :)

I only, say the past few months, started to read about how AI could do most of the coding for developing apps and of course I was skeptical.  Without trying it I guessed that maybe it would handle setting up the scaffolding for a project and adding snippits of code but actually developing an app from scratch seemed unlikely.

A few weeks ago I decided to dive in and see what AI could do.  The first AI tools I used to do this were Gemini and AWS Q Developer, now Kiro.  I wanted to see how I might use them to write my next generation version of the Karaoke program I originally wrote many years ago.  I setup a VS Code environment on a Hypervisor VM and started to Vibe code,a new term for me, and set to writing prompts to see what code was generated.  I was very impressed, if not AMAZED, at what it was doing!  I moved to also using the Kiro IDE and was impressed by the way it incorporated spec driven development.  This was only prototyped as a UI and backend was not hooked to it.  It was very useful to see how it helped aid in the UX design work.  Being able to actually see your pages in action and perform the navigation between them was very useful for developing a UX.

Well, I think this is the section you really wanted to hear about so lets dive in.   

I always ask Google/Gemini about the latest way to enhance your development and I started to see lots of AI development platforms being returned in my search..Since I had used FlutterFlow the Dreamflow platform caught my attention.

I stumbled across the Dreamflow Buildathon and thought why not give it a try.  I wondered about what would I try to build and of course some form of a mobile app was my only choice.  A big mistake I made when I started working on the project was that I felt I needed to develop my backend API first and then dive into Dreamflow and see if I could hook up the HTTP API to it.
I spent over a week learning how to setup a local environment on my VMs to build an AWS Gateway backed by Lambda functions to support my Dreamflow project.  I used Kiro to code the backend via its spec driven approach which is very impressive.  But, I soon began to realize this effort would likely not succeed so I looked around for some information about what Dreamflow really had to offer.  I found an excellent video which explained how Dreamflow could in fact be the fullstack development environment. I thought, wow, why am I coding the backend myself?

I guess you can say I pivoted into producing the app solely focused on using the DreamFlow platform.  I wrote up a text based requirements spec and pasted it into the Dreamflow prompt.  I had a name for the app so the Dreamflow AI was kind enough to use it.  The first version it produced was very impressive.  I decided to go with a Supabase SQL backend even though I had no experience with it and a little experience with SQL from a previous job. 

At first Dreamflow showed me a UI that only had sample data.  We worked together refining the pages and navigation before hooking it up to a real Supabase DB.  There have been some very difficult moments but overall I'm very happy and impressed with the first version of the application produced with the help of Dreamflow.  Dreamflow as my assistant we worked as a collaborative team and were able to work plow thru the  hurdles that encountered to produce a very impressive first version of ScrambleHub.  I did have to upgrade to the Pro version as I felt Github access was vital to tracking my iterative development in creation of this application.  I also needed a few more credits to get the App finished.  All in all the project as first submitted to Google Play took about 

It has been submitted in Google Play, and soon IOS, but I have to wait for approval before I can make it publicly available. 
For the Buildathon I have provided an internal test link that should allow you to review its functionality.  You can read
a synopsis about the app on this website: scramblehub.app/ with a video (basic) as well.  No matter what happens with the contest I'll continue to use Dreamflow and produce additonal versions of the app so 
that it can find its niche amongst its target audience. 

Thank You Dreamflow for motivating me to working into the wee hours of the morning and reigniting my passion for creating software.  ​​I feel that my journey has now evolved me into a true 'Renaissance Developer'.

I've decided to utilize a number of AWS services to implement the backend for Karaoke Cat.   This approach has many advantages even for a small app like KC.

When I first moved Karaoke Cat off of Redhat OpenShift, as they were no longer offering an affordable version for a small operation like mine, I moved the WSGI server to the Pythonanywhere environment as it was written in Python using bottle.  That worked very well but it was not my long term solution as it was not scalable.

I then moved the existing HTTP API to AWS Lambda.  Each route was implemented as an individual Lambda function which basically meant each function was its own small microservice.  The AWS API Gateway was utilized to provide the HTTPS access to the routes and each Lambda function.  The existing JS code required little modification to allow this to work.  It still is using the original HTTP API interface and the same JSON data is returned to the client.   That's how kc-db.com is functioning currently (As of April 2024) . 

MongoDB Atlas was used as the DB server in both the Pythonanywhere and AWS Lambda implementations.

The next step is to implement the KC version 2 HTTP API to support multiple vendors and their venues via MongoDB.  This also means supporting multiple song catalogs.  The development will take an API-first approach with the UI design and integration occurring after the API has been completed and tested.  

There are a number of Low Code/No Code platforms that have been created for developing mobile apps.   

One low code approach to mobile app creation is called Appgyver.  This platform was acquired by SAP.  It is built on top of the REACT web platform.  This means that apps developed in this way are basically hybrid web apps whose code behind is Javascript.   I went thru the online tutorials and the environment was fairly simple to use.   Some concepts were not explained well or were not in sync with the current version.  However, there is a series of videos where the more advanced concepts are explained nicely and example apps are created.  You can find these at Curiousity Lab.

Exploring the Flutter ecosystem you will come across something called FlutterFlow.  This is basically a WYSIWYG development environment which generates the underlying Flutter content for you.  I'm just starting to learn this approach to see how much quicker it will be to develop apps using it verse using just Flutter.   There are many online tutorials and videos for this environment which I have just started to view.  There are also some very nice Flutter dev courses at Udemy.  I am currently looking at two and both do a decent job describing the material.  Not yet sure which to recommend but both seem to adequately cover flutter.  The document set for Flutter is very comprehensive and located at Flutter Dev.  The documents for FlutterFlow are also quite extensive.

There are more platforms but I prefer to have some ability to write code so the no code alternatives are not what I'll choose.  Between these two platforms I'm still in the decision phase but I'm leaning towards FlutterFlow.  Not because its easier to use but because it seems to have a larger ecosystem behind it and more capability for the types of features that I'll want to build into my apps.  However, my final decision on this has not been made.

After a few attempts to restart working on projects for Geosyncracy I am now able to get back to focusing on improving my existing apps and exploring new ones.  After investigating how mobile development technologies have evolved, since first publishing HandsfreeETA and Karaoke Cat, it was obvious that continuing to use the same platforms was not feasible.  Both Cordova and jQuery mobile are not going to be supported so a new approach for cross platform apps to run on Android and IOS was needed.  

The technology that I will be diving into is produced by Google and is called Flutter which uses the Dart language.  While I'm an experienced software developer I know nothing about this new platform.  My approach will be to take a few courses to jump start my ability to redevelop my previous apps using Flutter/Dart.  I'll write additional posts to report on my progress and whether I felt this was the best alternative for writing mobile cross platform apps.

Over the last two months I've been working towards releasing an update to Handsfree ETA.  I'm close to publishing this new version that will make the app useful once again and be worth the download for Android users.   If you happen to read this post use the Contact section to send me a note and ask for a code so you can download the full version and use it for free.  My gift to anyone who has taken the time to read this blog post.

I had not worked on the app in a few years.   The Android OS was only version 2 when I built the original app and it is now at version 6.0.  The app was failing to work on many phones for lots of reasons.   Some were due to new restrictions imposed by the OS and many, admittedly, were due to coding mistakes on my part.  While fixing these issues I've learned a lot about how to support the features that the app requires in the current OS and better methods to test and develop the code.

It's not possible for app developers to test all the devices supplied by such a large number of manufactures.   We test on one or two real phones and we can test in the Android emulator but its hard to cover everything so compatibility problems are bound to surface.  We can only try our best to be sure we have tested enough of the app to ensure it has the best chance of functioning properly from device to device and OS version to OS version.   A very difficult job but an important one.

Once the app is published I'll write some additional blogs on how to overcome some of the major problems that prevented my app from working properly.  The info is available online, if you GOOGLE hard enough, but I want to summarize it, in one place, so it can prove helpful to other developers who might struggle with the same types of issues.  I'll be adding these blog posts over the next few months.

​-Regards

I have been very quiet since initially creating my first app called Handsfree ETA.  I have learned a lot about attempting to use a Hybrid approach to create mobile apps.  The  moral of this story is that no development environment will provide you with complete compatibility across platforms.  Even an approach that uses HTML5, CSS3 and Javascript.  The webkits from device to device, manufacturer to manufacture and Android version to Android version are just not the same.   This causes sublte differences.  One webkit may be more forgiving to a Javascript coding mistake than another.   Testing on as many devices as possible and modifying your program to use Javascript that works across devices is your only real option.   The use of the emulator can help but it was notoriously slow and painful.  Google has supposedly made this faster but I have not yet tried the latest emulator versions.  Is it really faster?  If you know please respond to this post.

However, I've recently discovered that Google has now made their V8 engine the default option for  later SDKs. They did this a while back; I just didn't know cause I didn't look.   Staying current is not an easy task but it's important and can save you lots of tie and frustration if you manage to do it.

I have not given up on the Hybrid approach.  The fact that V8 is now the default for the webkit engine on Android is a real good thing. Hybrid apps will run faster and be more predictable across devices, manufacturers and release.   Users are upgrading away from 2.4 as they buy new phones.  Android versions 4+ versions are now dominating the market so changing your apps to use V8 as the default is a good idea.

I've also been tinkering with some other things over the last year.  Like learning the latest jQuery Mobile version and  coming up to speed on the latest Phonegap releases.  If you stay away from updating the core versions of the open source used by your apps for too long you are looking at a lot of work and very possibly a rewrite of your code.   Open source authors have a desire to make their Platforms/SDKs better and will not sacrifice this for the sake of backwards compatibility.  I don't really blame them for this as they need to compete with similar platforms for market share.

I really just wanted to swipe the dust off my blog and give you a taste of what I've been up to.   I have a lot more to say about my latest project and I will write additional posts about my adventures to move to the latest versions of the platforms that I've tied to my development efforts.   

Stay tuned and we can take this journey together!

I have decided to release a trial version of my mobile phone application called 'Handsfree ETA'.  
The trial is very feature rich and is only limited in the following ways.  There is a limit on the number of trip plans (2) and marked locations (4) you can store.  You can't include a personal message in the ETA updates like you can in the paid version.  And, of course, there are Ads in the trial version.  The icon is a grey scale version of the colorful icon used for the paid app.  The paid version is only a $1.99, so, when you want to store more trip plans and mark more locations, or include messages in the ETA updates, just upgrade.  It's a bargain when you consider the problems caused by texting and driving.  

Oh yeah, if you ride a motorcycle you will really like that the app lets your friends know where you are when your meeting up for a ride, without having to stop!  Works great, I know, I ride too.  It really gives your family peace of mind knowing your safe and making progress to where your cruising takes you!

I was going to produce an expiring trial but I decided to allow people to use the trial indefinitely.  I really believe this app solves a problem that people experience while driving.  The need to text so someone else knows where you are is a real PROBLEM.   It's DANGEROUS and now very ILLEGAL.  People are going to jail when they get into serious accidents texting while driving which many times leads to loss of life.  

There is a campaign to have people take a pledge to never text and drive.  I have taken this pledge personally and I hope you will as well.  This app, now free, can provide you friends and family the information as to your whereabouts so you don't have to text it yourself.

Check out http://www.itcanwait.org/  and take the pledge yourself!  

Try the app and use it, as long as you want, for FREE, as long as you pledge to NEVER TEXT and drive!

Drive and Ride Safe!

The Founder of Geosyncracy and author of this very useful app introduced the app in Lowell at Motorcycle Night!
Watch what he had to say below.

Chelmsford, Ma - July 31, 2012 - Geosyncracy will be hosting a booth, tonight, at Motorcycle Night
in Lowell, Ma on Pawtuckett Blvd along the Merrimack river.  We will demo our first mobile application published yesterday on Google Play called Handsfree ETA.

It promises to be a fun night and there are always some great bikes to see!  We will also be having a very special, free raffle so come out and visit us!  You might just win something very special!

Handsfree ETA sends automatic text message updates to let people know when you plan to arrive to your destination without the need for any direct interaction on your part.  

The image to the left is the splash screen for the first product to be released, in just a few days, by GeoSyncracy. The image reveals the name of the product which will also be the domain name of the apps website.  I'll leave it to your imagination as to what the product does but based on the app icon and name I hope you can figure out it's intended purpose.   Just reply to this post with a guess?

The product will first be released on Google Play and by the end of August the iPhone.  The technology used to develop this product makes multi-platform support much easier.  Look on the about page for more details about how this app was created.

We are also going to be at Motorcycle Night in Lowell, MA on July 31st.  
For those attending I have a special offer that will be announced that night.

Here's the icon for my first app.  It was created by a Mass Art School of Design student who is entering his second year this coming September.  I think he did an Awesome job keeping it simple and relevant to what the app actually does.  Another student, at the same school, also entering her second year designed my splash screen and did an equally impressive job.  I will reveal that screen here as the app gets closer to launch.

I won't say more about what the app does but that it is near completion on the Android platform. A booth is still planned for Lowell Motorcycle Night on July 31st.  I hope to see my friends and former colleagues at that event providing moral support.

I have not blogged much or tweeted as I'm flat out completing the app and preparing it for launch on Android.  You can read about the technology used to produce this app on the About page; I plan to rapidly make the app available on additional mobile platforms soon after the launch on Android.  More on that to come in the next few months.