In this video, we're going to go through the simplest process possible. We're going to build an app for iOS and Android together in under 3 min.
AlmondBird is a unique framework that enables you to create iOS and Android apps with simple basic HTML knowledge. You code your pages in HTML like you would do your website and then you only need to store the static assets within the apps themselves (javascript, CSS, images, fonts, sounds, etc.).
The HTML will be served from your server, just like a normal page, but the whole process will become much more fluid as most of the static data is already on the client phone.
In short: the app acts as a webview which can serve local content in replacement to remote assets.
The typical user would be mostly individuals, small start-ups or people who need fast prototyping. Too often are iOS and Android apps just the same, and you are just spending energy transcribing an app from one language into another. It is a waste of time and money, especially for very simple basic apps. With AlmondBird, you can have only 1 engineer coding all your different platforms (iOS, Android, Web) without having to learn anything new.
We provide a simple example in the form of a Flappy Bird clone as a branch of the repo (see here). The images, javascript, fonts, css and sound assets (roughly 700 Ko in total) are stored within the app itself and are therefore not being downloaded by the app. The downloaded HTML from the server is only a few lines long (2 Ko) and connects the different elements. The HTML is being sent by a basic server the first time and is cached for future offline uses. Everytime your launch the app and you are online, the cache is refreshed all over again for the case that you reuse the app in offline mode.
For the HTML content: whenever the user will use the app while being online, it will refresh the content immediately and cache it.
For the assets: whenever you change the name of your static files, the App will download temporarily the files. Let's take an example: you changed your CSS and you want it to be reflexted in your apps, including the older version already released in the past. In order to do that, just update the name of the CSS file. The app will automatically download it as the asset with that new name is not present locally.
Click here to see the video of a simple walkthrough. Download the repository. You can simply checkout the demo by changing your branch to "Flippy Bird" in the project. The files are composed of the following: some images (the plane, the pipe, the cloud, etc.), two sound files , 1 font and 4 javascript files. No file other than the 2ko HTML file is requested from the server. Feel free to open the HTML file that is provided by the server from your computer - you'll find the URL in the config file.
You can start with a short course -- this will make you build a flappy bird clone as app. This course will bring you through all the main features.
You can modify the app icons, the app name, the app build name (com.mySuperDuperCoolapp.client for instance), the HTML endpoint, the app version name, the app version code, the splash screen icons, the splash screen color and the deeplink protocol (for instance: "myapp://"). More to come... someday.
You'll need the following free tools:
You can cache the following type of files:
We can always add more in the future if there is a request for it.
Upon set up of your app, you need to define a scheme name in your Config.json file under the name "deeplinkScheme". This will allow you to open the app by calling the app. For instance, if you use mycoolapp as a scheme, you can open the app by using the link mycoolapp://.
You can also add additional parameters that will be added to the URL upon opening the app depending on the "websiteURL" defined in the Config.json file. For instance, if your websiteURL is https://www.mywebsite.com and you create a deeplink in the form of mycoolapp://this/is/a/path, the app will automatically open https://www.mywebsite.com/this/is/a/path
To simplify, what we provide is a full screen webview with a local storage for static assets. By adding static files in the build, your app will shortcircuit any remote request from your HTML endpoint when the filename and file path match the one you have locally stored within the app. For instance: your webview sees the tag <script src="//www.myserver.com/path/to/jquery-1.0.5.js">. If you have stored a file called jquery-1.0.5.js within the app with the very same path, your webview will serve the content locally. If you have all the static files within the app, everything is loaded within a few miliseconds.
You should always give a unique name to your assets (MD5 hash of the file content for instance), so that whenever you update it on the server, it will be reflected within the clients.
You must be wondering what is the difference between our framework and some others already existing on the market.
You can think of certain hacks: imagine having different version of the assets. For instance: high resolution images on your local app, and low resolution if they need to be downloaded.
We're using the Apache2 licensing. So, yes, it's 100% free regardless of what you do with the App. For the source code, if you want to branch it or host it, you just need to keep a mention of the origin.
The cache will take the content of the HTML online the first time the app is launched, as well as everytime you'll launch the app while being online. It will then serve this content in the case the user of the app is offline.
Talking about speed is always a delicate topic, as it widely depends on the geographical location of your users. The little example app, a game we called "Flippy Bird" (one of the demo branches of the framework), ony needs to transfer 2 Ko with the server when online as all the static assets are stored locally. It would take 700 Ko to download it all if you would use a browser. While on a test session in South East Asia (Malaysia) on Edge connection, it took less than 1 second to launch the app vs. 2 minutes with a browser.
This framework accepts all languages, Angular.JS included. The difference that we have with most other frameworks is that you don't NEED to use it. The advantage of Angular.JS vs static HTML is in the filesize. Only, nowadays, for most uses with high internet speeds, it's not really the size that matters but the number of requests. It's not the few additional Ko in the requests that are going to ruin your user experience.
Moreover, how many people do you know who can code in Agular JS vs. the number of people who can code in HTML?
The advantage of having your app is that have additional capabilities, such as sending push notifications for instance if you implement it. Other advantages could be having your own icon, faster loading times, etc.
Feel free to contact us: cyrille@almondbird.com
We're originally a few friends friends who happened to work together in a same company. Feel free to check out our team page here - some of us work at Shileo, a really cool company selling food online.
By email: cyrille@almondbird.com
If it's an implementation question, just use StackOverflow, and send us an email with the link: cyrille@almondbird.com. If it's a bug, just use Github's Issue page on our project. If it's private, contact us directly: cyrille@almondbird.com
See here
