Taplytics is a native mobile A/B testing, feature flagging, and push notification platform that helps you optimize your Android / Android TV / Fire TV app!
How do I, as a developer, start using Taplytics?
The Taplytics team is available 24/7 to answer any questions you have. Just email support@taplytics.com or visit our docs page for more detailed installation and usage information.
getAllVariables to allow for getting information on all variables in the config at the moment.userBucketing option for user based bucketing enabled projectsNote: Contact support@taplytics.com to get your project user based bucketing enabled!
logging option to enable debug loggingaggressive option for visual editing on recycler viewssetUserAttributes that has a callback parameter to determine when the call has ended.FLAG_ONLY.TaplyticsNewSessionListener.resetAppUser.childFragmentManager.Improved performance of app lifecycle event tracking.
Fixed occurrences where potential memory leaks can happen.
Ensured that visual changes get applied from disk when launching the app with no internet connection.
Refactored Taplytics.delayLoad and Taplytics.startActivity. These now can handle multiple listeners and delay load properly short circuits when startActivity is complete.
Improved visual editing on ListViews and RecyclerViews inside of ViewPagers.
Modified all AsyncTasks to operate on separate thread pool for newer Android SDK versions
Support for visual editing on ListViews and RecyclerViews with row elements that are single Views. Previously only supported rows which are ViewGroups.
Enhanced support for visual editing on text elements with no IDs.
Improved performance of first-page experiment goals.
Track received push notifications immediately instead of waiting for app open.
Added extra sdk-side verification of deeplink URLs for link pairing.
startTaplytics was called.Updated the behaviour of Dynamic Variables with respect to sessions:
In the event that a new session begins, Taplytics will now ensure that async variables have their values updated in the event that they have changed in the new session. Further, sync variables will also have a new value so long as they are re-initialized.
Added support for ListView and RecyclerView header/footer visual editing.
Added manual push dismissed/received tracking. This is meant only for clients who do not use Taplytics to build notifications, but build themselves.
Use as follows:
Taplytics.trackPushReceived(tl_id, custom_keys)
Taplytics.trackPushDismissed(tl_id, custom_keys)
where tl_id and custom_keys are retrieved from the bundle within the Taplytics notification intent.
Greatly improved visual editing on carousels and ViewPagers.
Added manual push open tracking. This is meant only for clients who do not use Taplytics to build notifications, but build themselves.
Use as follows:
Taplytics.trackPushOpen(tl_id, custom_keys)
where tl_id and custom_keys are retrieved from the bundle within the Taplytics notification intent.
Added ability to aggressively force visual changes on elements that may be modified by code in the future.
For example, a TextView that may be updated in an activity's OnCreate previously would have overridden Taplytics' changes, but now it should remain the values sent by Taplytics. This currently works for Visibility and Text changes.
Simply add the "aggressive" starting option to Taplytics will enable this feature.
FLAG_DEBUGGABLE flag on the application info. Now, there is also a check on your applications BuildConfig.DEBUG parameter to add extra safety around this entire process.
debugCheckType" with options "flag" or "config" if you do not want both to be checked.isDebug" starting option, which allows you to manually control the debug status of a device based on your own parameters. For example, if you were to pass in BuildConfig.DEBUG as this option, the debug status would be determined based directly on the current value of that parameter.getRunningExperimentsAndVariations to be more closely tied to the completion of the propertiesLoaded callback.startNewSession function which allows for manually starting a new user session. This also allows for manually fetching new Taplytics experiments for the user if there are any. See the docs hereUpdate event saving for those who use multiple SDK keys for different environments.
Previously, stored events were not associated with a project and would be sent to the project associated with the current SDK key. This meant that stored events had the potential to be sent to the incorrect project. This mainly effected those using multiple SDK keys to debug.
Add some additional logs for support.
Add additional option to ignore fragment classnames in projects which heavily obfuscate activities and fragments, causing them to have different names upon each build.
Security optimizations. Taplytics will now encrypt all data. Taplytics data in of itself is not sensitive data. However, custom data appended to events as well as potential user attributes set by the client may contain sensitive data. While not easily obtained, rooted devices had the ability to view this data. This is now handled by encrypting all data saved on the device.
Reduced lag when editing List/Recyclers in debug mode.
Explicitly require HashMap in options for startTaplytics
Due to operations done within Taplytics, this can no longer be an ArrayMap and must explicitly be a HashMap.
Optimized and refactored ListView and RecyclerView visual editing.
Visual edits made on RecyclerViews are now far more reliable due to a change in the identification of which list cell needs to be changed. Visual edits on List/RecyclerViews also now operate much more efficiently.
Fixed bug in dynamic variables with numbers which are both floats or integers.
When a dynamic variable's default value was a float or integer, all variations were expected to be of the same type. This was problematic when parsing JSON, as the system saw any numbers with no decimal as an integer, even if the type was a float. This resulted in the default value always being returned. This has been handled and will no longer be an issue.
Various small efficiency improvements in width/height visual edits.
DelayLoad should no longer immediately return during liveUpdate builds.
delayLoad now waits for a pass/fail on the config request before triggering. Previously, on connected debug builds, it would trigger after visual edits have been applied, even if just from disk.
Track Adobe Analytics trackState calls.
Previously Taplytics would only track trackAction, but now it also allows for trackState
Added safety around new external integration methods.
Simple safety checks and catches to ensure no errors showing up. Errors are expected in these integrations and our attempts do deal with them, however they are squelched. This update just ensures that such errors don't reach crashlytics and cause confusion.
Update Taplytics internal Retrofit interceptor.
Taplytics uses a networkInterceptor to do a simple obfuscation of network traffic through Taplytics (using its own okKttpClient). This may not work depending on the app's okHttp/retrofit versions (older). While not technically an issue, extra safety has been added in this area.
Updated Flurry, Amplitude, Adobe, Localytics, and Mixpanel integrations to allow event handling on their newest SDK versions.
Flurry integration now also supports property maps.
Fixed error when user's country code does not have associated ISO language.
For example, es_LG is unknown by the Android system, and will no longer cause an error when the ISO3 language code is searched for.
Added additional socket call to better interact with the new experiment selector on the User Insights page.
Fixed ExperimentUpdatedListener returning wrong value on initial use of Shake Menu.
In a race condition for large projects, the listener was triggered before new updated values were cached fully. Additionally, if a project initially timed out, the SDK would not have the cached data to reference.
Decreased sensitivity of shake menu listener.
Using the most recent android build tools, it seems that the shake menu appears a lot more frequently. The low-pass filter used on the device accelerometer for detecting shakes has been increased to be far less sensitive.
Added startup safety for Taplytics (internal)
In past updates, safeties had been put in place during the startTaplytics call internally. More comprehensive checks, weak references for leak safety, etc. In this update, these checks and safeties have been extended to many of the static variables and their static initializations in core Taplytics classes.
Fixed slowdown in visual edits on ViewPagers
Previously there was a slight delay when applying visual edits to an element on a ViewPager. This slowdown has been eliminated in this update by preemptively making the visual update before the viewpager is visible.
Technical Explanation:
Android unfortunately does not contain a standard method to retrieve a fragment from a ViewPager by its position, but rather it only contains a getCurrentFragment method which returns the current position as an integer. Taplytics does not make use of getItem or instantiateItem as it may incidentally create a new instance of the fragment depending on the developer's implementation, and we wish to remain as non-intrusive as possible. Its common for developers to implement methods in which to track the fragments in a ViewPager, but as a library, Taplytics does not want to make assumptions of the existence of such functions.
In the past, Taplytics applied changes to every view child in the ViewPager, however this was deemed far too inefficient, especially within ViewPager with more than 5 pages. Soon after, Taplytics relied on a reflective call into the ViewPager's mCurrentFragment field to make visual changes, but this only allows changes to be made on the current fragment showing, which is where this mentioned delay originated.
Now, Taplytics is able to identify which views within a ViewPager require changes and apply them before the ViewPager is on the screen. This is due to a tagging system that identifies which fragment needs changes, which also allows for an efficient search for these fragments. Additionally, Taplytics will only change the current fragment as well as fragments directly to the left and right of the current fragment, allowing for the most efficient visual edits of ViewPagers yet.
Fix Taplytics not being able to properly track fragments on newest support libraries.
This is a simple Proguard issue. Android's FragmentManager contained a mExecutingTransactions field which Taplytics uses to ensure that certain interactions with the FragmentManager are safe. As an extra precaution, if there is an issue surrounding this field, Taplytics will not risk interacting with fragments.
In the most recent support fragment updates, this field was moved by Android, and so our tests picked up these changes and notified us of a necessary change within our own Proguard configuration which keeps this field's name.
Change base method used for finding views.
Taplytics previously relied on findViewById in base viewgroups to find views that need to be modified. This became unreliable over time as the applications changed given that ids can change.
Taplytics will now first check the view identifier first before the id. This means that if the name (identifier) of the view is changed to something new, Taplytics will not be able to modify it using the old experiment, and it will need to be set up again.
Fragments will now too rely on the identifier of the fragment container instead of the ID for similar reasons to the ones stated above.
Fixed an issue in which Android studio would output many warnings surrounding Proguard and inner classes.
findViewById for button click tracking. Only use resource identifiers.getUserAttributes for security. Replaced with getSessionInfo.For example, you now can start Taplytics as such:
Taplytics.startTaplytics(Context, ApiKey, Options, TIMEOUT, listener)
When this timeout is reached, Taplytics will continue and ONLY use values stored on disk for the remainder of the session.
Improve code block timeout and cache interaction.
Make fewer socket connection calls on debug app startup.
Kickoff all variableUpdated and visual editor changes with disk or default values immediately after timeout.
Devices which have a delay to start Taplytics (such as via segment) will now track the main activity start more consistently.
Debug devices which time out can now kick off pairing without needing to restart the app.
Taplytics.getUserAttributes(new UserAttributesRetrievedListener)..showusing the same tag, for example:
fragmentTransaction.addToBackStack("example tag");
exampleDialog.show(fragmentTransaction, "example tag");Updated geofence logic to ensure geofences won't be lost if they are not successfully added the first time.