Start With a Minimum Viable Product (MVP) Version of Your App

You've probably heard or read this advice before, but it pays to create a minimal or "skeleton" version of your app and use that for initial testing. There's a strong temptation when you start building your app to include every feature you can think of before you release it to beta testers. Why create just a bare bones version? There are several reasons, but the primary reason is so you don't have to rebuild half of your app when you start getting feedback about changes and improvements.

Years ago when "shareware" was a big thing, I wrote a do-it-yourself desktop database program. The program sold a lot of copies and a major PC magazine even featured it in an article about database management software. The problem was that I included every feature I could dream up before I released it, to try and make it the most versatile database software on the shareware market. As more people started using it I began to get all kinds of suggestions about things I should have done differently or functions that would be great to add to the program.

The first few changes I made were fairly small, but some of the suggestions people were making on my forum required major re-working of the program code. I ignored some of the "...wouldn't it be great if..." ideas, but there were other changes and additions that really needed to be included. I managed to make the modifications, but it became harder with each new feature I added since the program began to resemble a tire that had been patched too many times. The code got more and more interwoven and testing each new version became almost a full-time process.

With no-code you don't have to worry about "spaghetti code", but you can still end up with a program that doesn't flow well and requires major re-working each time you make a change if you start off with what you believe is a "finished" product. Inevitably, there are going to be some changes and additions needed once other people start using the app. It's much easier to create a clean, well-organized, easy-to-use application if you get feedback from actual users before you try building out the final product. 

Which Platform Should You Use?

You're starting a new project and you've decided to use a no-code or low-code platform to build your app - but which platform should you choose? There are more and more no-code and low-code app development platforms showing up every week and picking one to use can be really confusing. So how do you go about making that choice? Here are a few suggestions that may help you answer that question:

• Are you building a business-related app or a personal/social media type of application? Native mobile apps (programs designed specifically to run on Android or iOS devices) are generally the best bet if you're creating something that people will be using on their phone or tablet, especially if the app relies on features built into the device like the camera, GPS, biometric sensor, etc. However, web apps (optimized for mobile devices) are usually the best choice for any application that requires much data entry or analyzing detailed reports.

• My choices for platforms that are focused on building web apps include:

• Bubble.io - Bubble has a slightly higher learning curve than a lot of other platforms, but it allows you to build almost any type of application and it offers dozens of customizable templates. Bubble also has a wide range of tutorials contributed by users that show you how to build apps like Quora, Udemy, Medium, Quickbooks, and Instagram, among others. Hosting for your app is provided on Amazon Web Services (the leading cloud hosting provider).

• Caspio.com - Caspio works a lot like Bubble, with the platform divided into sections for building your data tables, designing the user interface (for forms and reports), and creating workflows based on event "triggers". As for infrastructure, Caspio is hosted on AWS and uses Microsoft SQL Server as its internal database system. Also, Caspio refers to itself as a "low-code" platform, although you can definitely build apps without adding any code. In fact, both Bubble and Caspio do allow you to add some JavaScript code to perform certain actions, so in that sense they're both "low-code" platforms.

• Zoho Creator - Zoho Creator is sort of a jack-of-all-trades. You can create desktop apps, native Android or iOS apps, or responsive mobile apps. It does have its own proprietary scripting language (Deluge) which you can use to provide customized features - that can be viewed as a plus or minus depending on your willingness to learn Deluge (although you can pick it up in a hurry). Zoho Creator also provides for a wide range of third party integrations, including all of the other Zoho products (Zoho Sheets, Zoho Books, Zoho CRM, etc.).

• My choices for platforms you would use to build native mobile apps include:

• Glide - If you need a fairly simple app and need it in a hurry, Glide is great option. There are a number of basic templates available that you can use as a starting point and end up with a nice-looking, easy-to-use app. Performance used to be a bit of a problem at times since Glide's only data source was Google Sheets - however, Glide now has its own database system in place, allowing for faster response time in storing and retrieving data.

• Appy Pie - Appy Pie is similar to Glide in that you can whip together a native mobile app in a hurry (and get it published to the App Store or to Google Play Store). However, you're pretty much restricted to picking a template, adding some pre-designed pages, and picking a particular theme. Anything more complicated usually requires integration with a third party application.

• GoodBarber - Building an app with GoodBarber often starts with selecting one of their 50 or more templates, the same as with Glide. However GoodBarber's templates are generally more polished, plus they provide more access to the native features on mobile devices - functions like beacons and geofences. In addition, you can build PWA's (Progressive Web Apps) with GoodBarber to provide users with an optimized mobile web application (which can also make use of certain native features of the mobile device, such as the camera or GPS).

• AppGyver - If you're determined to find a platform where you can take your app's source code with you if you leave, AppGyver (which is now part of software giant SAP) is probably your only option. You can actually take an Android app created on AppGyver with you as an APK file that can be imported directly into Android Studio. There are also at least two other unique features about AppGyver: 1) The platform is free for anyone or any organization with annual revenue under 10 million dollars and 2) You can even make an app for TV. 

Please leave a comment or email me if you have a favorite platform that I failed to include here.

Passing Parameters in Bubble

One of the most common actions in web design is passing information from one web page to another. If you're on a recipe website and ask for meals that use paprika, you'll probably see a new page load whose URL ends in something like "/?search=paprika". You pass parameters from one page in your Bubble app to another the same way. 

As an example, let's say you have an app that allows the user to enter the purchase price and projected lifetime of an asset (such as a lathe or drill press) and then try out different methods of depreciating that asset. Once the asset's purchase price and expected lifetime are entered, users can click a button to start a workflow in Bubble with the workflow's first (and only) action being to navigate to the page where they can select different depreciation scenarios. The action editor would look like this:

The destination is the page where the users select different depreciation methods ("depreciation"), the checkbox "Send more parameters to the page" is checked, and two parameters have been entered. Each parameter consists of a "key" and a value. In this case, the first key is named "q" (it could be any text string) and its value is the value of the asset purchase price. The second parameter's key is named "qq" and its value is the value of the asset lifetime. Any number of parameters can be passed to another page this way.

If the user entered a purchase price of $875 and an expected lifetime of 8 years, the tail end of the URL of the "depreciation" page would look like this:

/depreciation?debug_mode=true&q=875&qq=8

(notice our two parameters added onto the end of the URL)

There's nothing complicated about passing parameters like this in Bubble, but I read one explanation online that was a bit confusing, so I thought I would show a simple example of how it works. Hope this helps if anyone isn't clear about how to send data between pages.

Protect Your Data

Building a great app can be enormously satisfying - until someone steals the data you've collected for your company or a client. Having your app get hacked and data get stolen or corrupted can be a nightmare, for you and for your users. So what can you do to make sure that doesn't happen? 

There are multiple actions that you can take to protect sensitive data:

• Activate "SSL" (Secure Sockets Layer) protection if it's available to you. SSL (or its successor, Transport Layer Security) uses sophisticated encryption algorithms to scramble data in transit between a server and a user's browser or between two apps, preventing hackers from reading or copying the data as it's being transmitted.
• Force users to log in (at least to pages containing sensitive data). It may also be a good idea to enforce rules about how complex the user's password should be and to require changing the password periodically. 
• Consider automatically logging out users after a certain period of inactivity.
• Set up access rules for any page in your app that displays sensitive data. There are really three layers to this type of security:
• Mark those pages as private so that the app knows to restrict access.
• Set up "roles" for users so that only users with the proper role (administrator, manager, supervisor, etc.) can access a particular page that's marked as private.
• Assign "permissions" to users who do have access to a protected page (that is, whether a particular user can just view the page, or can view and edit data on the page, or view, edit, and delete data, and so on).
• Avoid using private API keys or tokens on a page in your app - restrict their use to workflows.
• If the platform you're on (and the plan you're on) provide the ability to encrypt and decrypt specific data fields, consider keeping fields containing sensitive data encrypted and only decrypt them when actually using those fields in the app.
• Avoid using third-party plugins to process sensitive data, unless the plugin is a standard add-on such as Stripe or MailChimp.
• Build in change logs or other ways to audit user additions, edits and deletions to sensitive data.

Yet Another "Universal" Android App

A few days ago I came across another "universal" app for android phones (see my previous post "A Universal WebView Android App"). This particular app template is from Sherdleapps and is available on codecanyon.net: (https://codecanyon.net/item/universal-full-multipurpose-android-app/6512720).

According to Sherdleapps this does qualify as a no-code app. If you have changes you want to make, you can choose to make those modifications by using the company's visual App Builder for free. The App Builder's drag and drop interface lets you  customize the app the way you want it without any need to make code changes manually. Once you've finished configuring your app, you can use the provider's online build service to compile your application into an executable APK that you can run on your own phone or deploy to the Google Play Store. According to Sherdleapps there's no software to install, just click ‘build’ and download your app. 

One note about the App Builder. The documentation says that once you purchase a license you have lifetime free access to the App Builder to customize the application. However, you only have one month of unlimited access to their build service - after that you need to use Android Studio to convert your customized template into an executable APK file. And as far as the App Builder goes, you can modify any of the features included with the app, but it doesn't allow you to add new features.

So what features are included in the app? According to the documentation you can offer:

• The ability to handle a wide variety of content - Wordpress posts and articles, videos and livestreams, WebViews, social media posts, WooCommerce, radio streams and podcasts, photos, and audio streams.
• In-app purchases.
• Admob advertising.
• Push notifications.
• A built-in media viewer/player.
• Flexible navigation.
• Custom actions - make an intent to another app or open a URL from the menu.

The "regular" license for the "Universal" Android app is $29, but there are two types of license and the terms are fairly complicated. To read about the licensing (and other features of the app) in detail go to:

https://codecanyon.net/item/universal-full-multipurpose-android-app/6512720

The New Glide

 

Recently I wrote a post about constructing a simple mobile app on Glide (www.glideapps.com). At the time I mentioned that I liked using the platform, but that it was limited by the need to use Google Sheets as the backend database (and by other factors, like a lack of templates). However, all that changed last month when Glide released version 2.0, which includes a number of new features.

The biggest change, in my opinion, is the release of "Glide Tables" the platform's proprietary database. Glide Tables are much faster than linking to Google Sheets, plus they're more scalable and they allow you to access the same data tables from multiple apps. You can still use Google Sheets as your database, but that's optional now.

Another major change is the addition of a bunch of new components, including:

• Webhooks (A webhook or web callback is a way for an app to provide data to other applications as it happens)
• Large scale (1 GB) file uploads
• Barcode scanning
• New button styles
• Satellite maps
• Sound effects
• Hint components

You'll find some other improvements too:

• Tablet and desktop views of your app in addition to the smartphone view (paid plans only)
• A new, much faster (open source) data editor
• A re-designed App Builder
• Additional team collaboration features
• An "Action Editor" that lets you build sequences of actions (workflows) with conditional branching capability
  
• A new dashboard
• Hundreds of new templates

Glide's pricing structure has also changed. The "Free" plan is now called the "Personal" plan to indicate that's it's intended primarily for personal, rather than commercial use (you're still limited to 500 rows of data on the Personal plan). The "Pro" plan, which allows 25,000 data rows and provides phone, tablet and desktop views, is now $32/month ($24/month when paid annually).

You can go to https://www.glideapps.com/blog/introducing-glide-2.0 for additional information on the new version of Glide.

Handling Yes/No Fields in Bubble

If you've used a "yes/no" (boolean) field in Bubble or on other platforms, you know they can be a little tricky to work with. Here's an excerpt from "Learning Visual (No-Code) Programming Step by Step with Bubble" that explains a way to make life with yes/no fields a little easier:

I had built a "to-do" list app with a "finished?" yes/no field to indicate whether or not a given "to-do" had been completed and I decided to add a filter to the listing page to let the user display all todos, finished todos, or unfinished todos. The problem I ran into is that Bubble's yes/no field treats an empty value as “no”. 

I assumed I could display finished to-dos or unfinished to-dos by adding a constraint to the repeating group that loads the to-do records. If the user chose a filter value of "yes" it would display finished records, while a filter value of "no" would show unfinished records. And if the user left the filter blank the repeating group would ignore an empty constraint and display all to-do records in the database. However, because a yes/no field sees an empty value as “no” the app displayed just the unfinished records whether the filter value was "no" or blank.

So what was the solution? I changed the type of the “Finished” field from yes/no to “boolean” (“boolean” being an "option set" that I created that had just two values, “yes” and “no”). Then I edited my sample data and reset the “Finished” field in each record to either the "yes" or "no" value in the option set. 

Once that was done I went back to design mode for the Todo Listing page and placed a dropdown box above the repeating group and named it “Dropdown Filter Finished”. Then I set the “Choices style” to “Dynamic”, the “Type of choices” to “Boolean”, the “Choices source” to “All boolean”, and the “Option caption” to “Current option's Display”. The property editor for the dropdown looks like this:

Next I opened the property editor for the repeating group, clicked on “Data source” to display the constraints, and added a constraint “Finished=Dropdown Filter Finished's value”. By changing the “Finished” field's data type to the “boolean” option set, the constraint now included a true “empty” value. 

At that point, the property editor for the repeating group looked like this:

Now the repeating group that displays the "to-do" records showed all todo records if nothing was selected in the dropdown (filter Finished) box, all completed todos if “yes” was selected, and all the unfinished todos if “no” was selected.

There are a lot of situations where a "yes/no" field is a good choice, but there may also be occasions when you want to use a boolean value instead.