Develop Faster in Android Studio with the Optimizely IntelliJ Plugin
Optimizely Engineer, Tom Zurkan is all about efficiency. He built an IDE plugin, making it easier for developers to use Optimizely in all IntelliJ based products such as AndroidStudio, IntelliJ, GoLand, and PyCharm. Recently, Tom showcased his work in a mobile development session, where he explained how Optimizely’s iOS and Android SDKs work. He also
Optimizely Engineer, Tom Zurkan is all about efficiency. He built an IDE plugin, making it easier for developers to use Optimizely in all IntelliJ based products such as AndroidStudio, IntelliJ, GoLand, and PyCharm.
Recently, Tom showcased his work in a mobile development session, where he explained how Optimizely’s iOS and Android SDKs work. He also demonstrated how to use the IDE plugin to integrate feature flags and experiments more efficiently in Android Studio. Below are the key points from the session, which showed how Optimizely enables mobile development teams to manage features and experiments without extraneous app store updates. You can check out the full video here.
What can feature flagging do for mobile development teams?
Feature flags allow you to roll back, or suppress, app code without additional app store updates. Ideally, errors are detected before you submit to the app stores, but it’s nearly impossible to replicate every possible scenario that occurs out in the wild. Nobody wants a bug or a poor-performing feature tanking metrics and spurring negative app store reviews. Feature flagging and remote configuration mitigate these risks.
Remotely configuring a feature can mean enabling functionality for internal testers, beta groups, regions, premium users, or a percentage of your entire audience. Or it could mean updating how the feature behaves when enabled for said groups. The Optimizely UI allows feature toggling, gradual rollouts, tests, and updates without additional code deployments. Mobile development teams can limit the blast radius when bugs arise, avoid fire drills, iterate, and validate new features with real users in real-time.
How can you update app features without sending a new version to the app stores?
Optimizely Full Stack and our free feature flagging product Rollouts use the same lightweight SDKs to give product development teams the tools to manage features and experiments.
At a high-level, the SDKs are dynamically updated by a JSON datafile that relays information from the Optimizely dashboard to configure your application based on actions provisioned administrators can perform there.
For example, you can control which features are enabled for which audience, see if any feature modifications exist and if experiments are running without rebuilding the app. Optimizely’s SDKs consistently bucket users for A/B testing and feature provisioning. Event tracking measures the success of the experiments.
Using the IntelliJ plugin for faster integration in Android/Java
The plugin provides shortcuts to look up and populate feature keys, variable keys, experiment keys, attribute keys, and event keys, as defined in the Optimizely dashboard. Below is an example using Android Studio to populate a feature key and its variable key in place. Autocomplete is also available in Go, Java, Kotlin, and Python if you are using a different language or feel more confident with using keyboard shortcuts.
You can use option-o e and ‘option-o f to list experiment and feature keys. Option-o v will list the variation or variable depending on the last experiment or feature chosen by auto-complete or from the options menu. Below is an example using the keyboard shortcuts. Notice how the feature variable type is not filtered.
You can also link through from the feature or experiment you’re working on in Android Studio to where it lives in the Optimizely dashboard with just a couple of clicks.
Lastly, Tom has added a debug dialog that allows you to try different combinations and audiences from a debug dialog. Below is an example of the debug dialog. In the first run, the user is not bucketed into the experiment because they do not meet the targeted audience’s conditions. The dialog output specifies exactly why the user does not match the audience. In the Java example below, adding a browser type will include the user in the audience. So, we add an attribute, set it to “chrome” and run again. Now, we are bucketed into the experiment. This would work in the same way for Android, but rather than browser, you might add audience attributes like locale, subscription status, or app/OS version.
Watch the full session with Tom to learn more about making your mobile apps more dynamic and resilient with feature flagging and experimentation. Not ready to invest in experimentation, but want the benefits of feature flagging and remote configuration? Try our free Rollouts product.