Development Best Practices
You must provide native libraries for the platforms which:
- Use almost no storage space on the device
- Use almost no resources (CPU, GPU, RAM) of the device
- Use no intrusive permissions
- Do not eat up on the count of available methods (e.g. method limit in Android). The Dalvik Executable(DEX) specification limits the total number of methods that can be referenced within a single DEX file to 65,536.
- Do not crash host App in any circumstance.
- Have appropriate logs exposed which can help identify run time issues
- Is able to classify between host App & SDK issues
- Is able to scale with vast variety of Device Densities (if there is a UI component in the SDK)
- Do almost no operation on UI thread
- Is not a security threat to the host App.
- Has almost no 3rd party library dependencies
- Is tested on vast variety of OS versions (especially the older ones and the newest ones) along with vast variety of device manufacturers
- Prevent crashes of host app (Use UncaughtExceptionHandler for this; https://www.intertech.com/Blog/android-handling-the-unexpected/)
Data Security Best Practicies
API key: API key is generally given to app developers to authorize the requests made to the sdk. This is good way to analyze sdk usage by particular app as well. However API keys are not safe enough because anyone can capture it over the wire and bombard the sdk with unsecure requests.
AWS Sig V4 or similar: AWS (and other cloud providers) provides signature mechanism which allows each request to authenticate itself before hitting the underlying business logic. See more details here: http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html And here: https://docs.microsoft.com/en-us/azure/app-service-mobile/app-service-mobile-auth
Short lived urls: Most cloud service providers provide short lived urls for their CDN. These are good ways to secure your endpoints from DOS attacks as you can decide the life span of such urls. Check our more here: http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-signed-urls.html And https://yossidahan.wordpress.com/2012/03/31/implementing-a-platform-for-exchanging-files-on-windows-azure/
Distribution Best Practices
Signing the SDK
- pro-guard rule file should be included in SDK.
- Put following in of defaultConfig of build.gradle (ref: http://stackoverflow.com/questions/38503434/gradle-are-proguard-configurations-inherited/38520637#38520637)
- consumerProguardFiles ‘proguard-rules.pro’
Mobile SDKs can be distributed via:
- Public jCenter repositories (https://inthecheesefactory.com/blog/how-to-upload-library-to-jcenter-maven-central-as-dependency/en)
- Public Maven Central repositories
How many of you have done mobile functional test automation? I am sure many.
How many of you have done it by handwritten code? I am sure many.
How many of you have faced a need of ability to manage & reuse the test cases in a much better and brainless way? I am sure many.
How many of you have used a test management tool with a test automation tool to achieve this? I am sure only a few (I actually searched very vast on Google to get a reference before starting this project, however not even a single line of code was shared anywhere).
Here comes Wheat; a bridge between Appium & RedwoodHQ. Wheat allows you to create & reuse your test cases in RedwoodHQ in more usable way (drag-and-drop) and have them getting executed in mobile emulators or devices via Appium. Continue reading
A client of ours decided to launch their app around three years after the development of their MVP. Since we did not want to miss the bus to the app stores, we decided to get at least the bare minimum of features on the app, and then provide the complete experience by doing incremental updates.