Develop Reference

Events not firing in Google Analytics via Google Tag Manager

I have been searching high and low for an answer on this and I am completly dumbfounded.
I am implementing simple click and page tracking in my Android app using GA, running this through GTM. All my "Screens" are visible in realtime in GA but I can't get "Events" to appear at all.
Well actually I can but the behaviour seems very bizarre. If I do not include a "Label" and a "Value" I can see the events appear. However if I add them (either as just a constant or a data layer variable) all events stop. I have confirmed the variables I want in "Label" and "Value" are coming through as I made a container with those values as "Category" and "Action" and could see them as expected in real time.
This leads me to think the app side implementation is perfectly fine but there is an issue with my tag in GTM. (Obviously not the Trigger as that too works when expected).
Ideally I would like to do something like this (the variables are data layer variables):
But this doesn't work. I see no Events.

The Event Value should be a number, not a string. Shuffle the fields, for example - Action - Click on: {{GTM - Click Target}}, Label - {{GTM - Click Value}}, and leave the value empty, this will fix your problem.

Make sure, you have correctly setted up Click listener.
Enable when defines when is listener available and where is applied to the all DOM elements.
Fire ON defines conditions, so in your case it could be {{event}} equals gtm.click or {{event}} equals gtm.linkClick .
This is the most common pitfall when setting listeners

How to handle UI based Navigation in Cross Platform Apps?

Assume that you have a cross platform application. The application runs on Android and on iOS. Your shared language across both platforms is Java. Typically you would write your business logic in Java and all you UI specific part in Java (for Android) and Objective-C (for iOS).
Typically when you implement the MVP pattern in a cross platform, cross language application you would have the Model and the Presenter in Java and provide a Java interface for your Views which is known to your presenters. This way your shared Java presenters can communicate with whatever view implementation you use on the platform specific part.
Lets assume we want to write a iOS app with a Java part which could be shared later on with the same Android app. Here is a graphical representation of the design:
On the left side there is the Java part. In Java you write your models, controllers as well as your view interfaces. You make all the wiring using dependency injection. Then the Java code can be translated to Objective-C using J2objc.
On the right side you have the Objective-C part. Here your UIViewController's can implement the Java interfaces which where translated into ObjectiveC protocols.
Problem:
What I am struggling about is how navigation between views takes place. Assume you are on UIViewControllerA and you tap a button which should bring you to UIViewControllerB. What would you do?
Case 1:
You report the button tap to the Java ControllerA (1) of UIViewControllerA and the Java ControllerA calls Java ControllerB (2) which is linked to UIViewControllerB (3). Then you have the problem that you do not know from the Java Controller side how to insert the UIViewControllerB in the Objective-C View hierarchy. You cannot handle that from the Java side because you have only access to the View interfaces.
Case 2:
You can make the transition to UIViewControllerB whether it is modal or with a UINavigationController or whatever (1). Then, first you need the correct instance of UIViewControllerB which is bind to the Java ControllerB (2). Otherwise the UIViewControllerB could not interact which the Java ControllerB (2,3). When you have the correct instance you need to tell Java ControllerB that the View (UIViewControllerB) has been revealed.
I am still struggling with this problem of how to handle the navigation between different controllers.
How can I model the navigation between different Controllers and handle the cross platform View changes appropriately?

Short answer:
Here is how we do it:
For simple "normal" stuff (like a button that opens the device camera or opens another Activity/UIViewController without any logic behind the action) - ActivityA directly opens ActivityB. ActivityB is now responsible communicating with the app shared logic layer if needed.
For anything more complex or logic dependent we're using 2 options:
ActivityA calls a method of some UseCase which returns an enum or public static final int and takes some action accordingly -OR-
Said UseCase can call a method of a ScreenHandler we registered earlier which knows how to open common Activities from anywhere in the app with some supplied parameters.
Long answer:
I'm the lead developer in a company using a java library for the application's models, logic, and business rules which both mobile platforms (Android and iOS) implement using j2objc.
My design principles come directly from Uncle Bob and SOLID, I really dislike the usage of MVP or MVC when designing whole applications complete with inter-component communications because then you start linking each Activity with 1 and only 1 Controller which sometimes is OK but most of the times you end up with a God Object of a controller that tends to change as much as a View. This can lead to serious code smells.
My favorite way (and the one I find cleanest) of handling this is breaking everything up into UseCases each of which handles 1 "situation" in the app. Sure you can have a Controller that handles several of those UseCases but then all it knows is how to delegate to those UseCases and nothing more.
Additionally, I don't see a reason of linking every action of an Activity to a Controller sitting in the logical layer, if this action is a simple "take me to the map screen" or anything of this sort. The role of the Activity should be handling the Views it holds, and as the only "smart" thing living in the life cycle of the application, I see no reason it can't call the start of the next activity itself.
Furthermore, Activity/UIViewController lifecycle is too complex and too different from each other to be handled by the common java lib. It is something I view as a "detail" and not really "business rules", each platform needs to implement and worry about, thus making the code in the java lib more solid and not prone to change.
Again, my goal is to have each component of the app be as SRP (Single Responsibility Principle) as it can be, and this means linking as few things together as possible.
So an example of simple "normal" stuff:
(all examples are totally imaginary)
ActivityAllUsers displays a list of model object items. Those items came from calling AllUsersInteractor - a UseCase controllerin a back thread (which in turn also handled by the java lib with a dispatch to main thread when the request is completed). The user clicks on one of the items in this list. In this example the ActivityAllUsers already has the model object so opening ActivityUserDetail is a straightforward call with a bundle (or another mechanism) of this data model object. The new activity, ActivityUserDetail, is responsible of creating and using the correct UseCases if further actions are needed.
Example of complex logic call:
ActivityUserDetail has a button titled "Add as a friend" which when clicked calls the callback method onAddFriendClicked in the ActivityUserDetail:
public void onAddFriendClicked() {
AddUserFriendInteractor addUserFriend = new AddUserFriendInteractor();
int result = addUserFriend.add(this.user);
switch(result){
case AddUserFriendInteractor.ADDED:
start some animation or whatever
break;
case AddUserFriendInteractor.REMOVED:
start some animation2 or whatever
break;
case AddUserFriendInteractor.ERROR:
show a toast to the user
break;
case AddUserFriendInteractor.LOGIN_REQUIRED:
start the log in screen with callback to here again
break;
}
}
Example of even more complex call
A BroadcastReceiver on Android or AppDelegate on iOS receive a push notification. This is sent to NotificationHandler which is in the java lib logical layer. In the NotificationHandler constructor which is constructed once in the App.onCreate() it takes a ScreenHandler interface which you implemented in both platforms. This push notification is parsed and the correct method is called in the ScreenHandler to open the correct Activity.
The bottom line is: keep the View as dumb as you can, keep the Activity just smart enough to handle its own life cycle and handle its own views, and communicate with its own controllers (plural!), and everything else should be written (hopefully test-first ;) ) in the java lib.
Using these methods our app currently runs about 60-70% of its code in the java lib, with the next update should take it to the 70-80% hopefully.

I would recommend that you use some kind of slot mechanism. Similar to what other MVP frameworks use.
Definition: A slot is a part of a view where other views can be inserted.
In your presenter you can define as many slots as you want:
GenericSlot slot1 = new GenericSlot();
GenericSlot slot2 = new GenericSlot();
GenericSlot slot3 = new GenericSlot();
These slots must have a reference in the Presenter's view. You can implement a
setInSlot(Object slot, View v);
method. If you implement setInSlot in a view then the view can decide how it should be included.
Have a look at how slots are implemented here.

In cross platform development sharing what I call a "core" (the domain of your application written in Java), I tend to give to the UI ownership of which view to display next. That makes your application more flexible, adapting to the environment as needed (Using a UINavigationController on iOS, Fragments on Android and a single page with dynamic content on the web interface).
Your controllers should not be tied to a view, but instead fulfill a specific role (an accountController for logins/logouts, a recipeController for displaying and editing a recipe, etc).
You would have interfaces for your controllers instead of your views. Then you could use the Factory design pattern to instantiate your controllers on the domain side (your Java code), and the views on the UI side. The view factory has a reference to your domain's controller factory, and uses it to give to the requested view some controllers implementing specific interfaces.
Example:
Following a tap on a "login" button, a homeViewController asks the ViewControllerFactory for a loginViewController. That factory in turn asks the ControllerFactory for a controller implementing the accountHandling interface. It then instantiates a new loginViewController, gives it the controller it just received, and returns that freshly instantiated view controller to the homeViewController. The homeViewController then presents that new view controller to the user.
Since your "core" is environment-agnostic and only contains your domain & business logic, it should remain stable and less prone for edits.
You could take a look at this simplified demo project I made which illustrates this set-up (minus the interfaces).

What is the best way to use threading on a sorting algorithm, that when completed, creates a new activity and gives its data to the new activity?

I will start this by saying that on iOS this algorithm takes, on average, <2 seconds to complete and given a simpler, more specific input that is the same between how I test it on iOS vs. Android it takes 0.09 seconds and 2.5 seconds respectively, and the Android version simply quits on me, no idea if that would be significantly longer. (The test data gives the sorting algorithm a relatively simple task)
More specifically, I have a HashMap (Using an NSMutableDictionary on iOS) that maps a unique key(Its a string of only integers called its course. For example: "12345") used to get specific sections under a course title. The hash map knows what course a specific section falls under because each section has a value "Course". Once they are retrieved these section objects are compared, to see if they can fit into a schedule together based on user input and their "timeBegin", "timeEnd", and "days" values.
For Example: If I asked for schedules with only the Course ABC1234(There are 50 different time slots or "sections" under that course title) and DEF5678(50 sections) it will iterate through the Hashmap to find every section that falls under those two courses. Then it will sort them into schedules of two classes each(one ABC1234 and one DEF5678) If no two courses have a conflict then a total of 2500(50*50) schedules are possible.
These "schedules" (Stored in ArrayLists since the number of user inputs varies from 1-8 and possible number of results varies from 1-100,000. The group of all schedules is a double ArrayList that looks like this ArrayList>. On iOS I use NSMutableArray) are then fed into the intent that is the next Activity. This Activity (Fragment techincally?) will be a pager that allows the user to scroll through the different combinations.
I copied the method of search and sort exactly as it is in iOS(This may not be the right thing to do since the languages and data structures may be fundamentally different) and it works correctly with small output but when it gets too large it can't handle it.
So is multithreading the answer? Should I use something other than a HashMap? Something other than ArrayLists? I only assume multithreading because the errors indicate that too much is being done on the main thread. I've also read that there is a limit to the size of data passed using Intents but I have no idea.
If I was unclear on anything feel free to ask for clarification. Also, I've been doing Android for ~2 weeks so I may completely off track but hopefully not, this is a fully functional and complete app in the iTunes Store already so I don't think I'm that far off. Thanks!

1) I think you should go with AsynTask of Android .The way it handle the View into `UI
threadandBackground threadfor operations (Like Sorting` ) is sufficient enough to help
you to get the Data Processed into Background thread And on Processing you can get the
Content on UI Thread.
Follow This ShorHand Example for This:
Example to Use Asyntask
2) Example(How to Proceed):
a) define your view into onPreExecute()
b) Do your Background Operation into doInBackground()
c) Get the Result into onPostExceute() and call the content for New Activty
Hope this could help...

I think it's better for you to use TreeMap instead of HashMap, which sorts data automatically everytime you mutate it. Therefore you won't have to sort your data before start another activity, you just pass it and that's all.
Also for using it you have to implement Comparable interface in your class which represents value of Map.
You can also read about TreeMap class there:
http://docs.oracle.com/javase/7/docs/api/java/util/TreeMap.html

How to perform Redo Undo operation in EditText

I want to know is there any method or any link or tutorial to perform redo undo operation in Android edittext. If any one knows than please let me know.

Quick note on the Antti-Brax/Divers(Kidinov) solution. It works great, except if you try to use it with a TextView post-API 23, you'll run into problems, because guess-what, Google actually added a hidden UndoManager (android.content.UndoManager) and didn't document it or make it obvious it was there. But if you have a hard/bluetooth keyboard in Marshmallow or Nougat and hit ^Z or SHIFT-^Z, you'll get undo/redo.
The problem comes if you're already using Antti-Brax's class with an EditText, and you also hook it to ^Z and shift-^Z, you'll run into problems with anyone using a hard keyboard. Namely the ^Z will trigger BOTH the native and Antti-Brax's undo, leading to two undos simultaneously, which isn't good. And after a few of them, you'll probably get a Spannable out of bounds crash.
A possible solution I found is to subclass the TextView/TextEdit/whatever and intercept the undo/redo calls from the TextView so they don't run as follows:
#Override
public boolean onTextContextMenuItem(int id) {
int ID_UNDO, ID_REDO;
try {
ID_UNDO = android.R.id.undo;
ID_REDO = android.R.id.redo;
} catch (Resources.NotFoundException e) {
ID_UNDO = 16908338; // 0x1020032
ID_REDO = 16908339; // 0x1020033
}
return !((id == ID_UNDO) || (id == ID_REDO)) && super.onTextContextMenuItem(id);
}
Those magic id numbers were found here, and are used only as a backup if the android.R.id.undo values aren't found. (it also might be reasonable to assume that if the values aren't there the feature isn't there, but anyway...)
This is not the best solution because both undo trackers are still there and both are running in the background. But at least you won't trigger both of them simultaneously with ^Z. It's the best I could think to do until this gets officially documented and the getUndoManager() methods of TextView is no longer hidden...
Why they made a feature you can't turn off (or even know if it was there or not) "live" in released Android I can't say.
I just opened an issue on Android's issue tracker if anyone wants to follow this.

There is an implementation of undo/redo for Android EditText in
http://credentiality-android-scripting.googlecode.com/hg/android/ScriptingLayerForAndroid/src/com/googlecode/android_scripting/activity/ScriptEditor.java
The code works but does not handle configuration changes properly. I am working on a fix and will post here when it is complete.
My Google search was :-
android edittext onTextChanged undo

I know this is an old question, but as there is no accepted answer, and this is an issue I've tackled myself from many angles, I'd like to add my solution in case it helps anyone. My answer is probably most relevant to large (1,000words+) volumes of text editing apps that require this feature.
The simplest way to resolve this problem is to make periodic copies of all text on screen, save it to an array and call setText() every time the Undo method is called. This makes for a reliable system, but it isn't ideal for large (i.e. 1,000words+) text editing apps. This is because it:
Is wasteful. It could be that only one word changes in a two thousand word document, so that's one thousand, nine hundred and ninety nine words needlessly committed to memory.
Can lead to performance issues, as some low-tier hardware struggles with rendering large amounts of text. On some of my test devices, this method can lead to freezes of a few seconds whenever Undo is called.
The solution I currently use is comparatively complex, but I've published the results in a library here.
Essentially, this library saves a copy of text as soon as a user begins typing, and then another copy of text once they've stopped typing for a set amount of time (in my case, two seconds). The two text strings are then compared, and the altered section of text returned, the indexes where the alterations occured, and details on whether or not the change was an addition of new text, a deletion, or a replacement of old text with new text.
The net result is that only the necessary text is saved, and when Undo is called, there is only a local delete(), replace() or insert() call, which makes for much faster operations on large text fields.

Here is the undo/redo implementation that was linked to from Gary Phillips' answer extracted into a reusable and universal undo/redo plugin for any widget that descends from a TextView. I added some code for persisting the undo history.
http://code.google.com/p/android/issues/detail?id=6458#c123
Hope this helps.

To preserve EditText Styling with regards to undo:
You can create an ArrayList<EditText> or ArrayList<String> (String containing html text) to store your last 10 (for example) actions. So ArrayList [0] would contain html text from your first action and ArrayList [9] would contain html text from your very last action. Each time the user taps "undo" in your app, you would apply ArrayList [size()-1] to your EditText and then remove ArrayList [size()-1] from your Array.

Android Patterns: A Spinner where every item launches a different Activity

I'm trying to build a complex form where almost all of the elements are optional. It starts with just a single field and an "add element" button. When you click add, the form shows a Spinner of the types of elements you can add to the form (location, photo, detailed note, timestamp other than "now", etc). When you select an item, it will launch an Activity, and each item has a different associated Activity.
In addition, each choice will have several bits of data, which it would be nice to store "with" the Activity somehow:
An icon and the displayed name in the Spinner
A key for storing the data in the db (as well as passing to a webservice)
A layout for how to display the result on the original form (i.e. a thumbnail for the photo, the lat/lon for the location, etc)
I was considering a set of classes that all extend an abstract FormElement class, and would have static elements for each of the above extra pieces of data. (An additional bump for this solution is how much of a pain Resources are in a static context.)
How can I make this as clean and maintainable as possible? I'd really not enjoy editing five different files to add a new type of element to this form. (Mostly because I can guarantee I'll miss one and spend hours chasing down unbugs.)

A few tips...
Unit tests will prevent "unbugs" :)
When each Activity has obtained the information it needs from the user, call Activity#setResult() with an Intent that contains your per-type data. Intent supports all the Bundle methods, so you can set different types of data as needed.
To support #2, make sure you're using Activity#startActivityForResult(Intent,int) to launch it, and listen for the result in Activity#onActivityResult(int,Intent)
I would probably maintain the list of available "element" types for use with the SpinnerAdapter (e.g., ArrayList<Class<? extends AbstractFormElement>>, and invoke static methods like .getDisplayName(), .getActivityClass(), etc, in the Adapter's getView() method, in order to determine what to display and what Activity to launch.
In this way, your list would actually contain things like { MyPhotoElement.class, MyTextElement.class, MyDateElement.class, ...}).
As each element is added to the form, add it to an ArrayList<AbstractFormElement>, which will be used to back another Adapter for a ListView. That adapter will dispatch the inflation of a custom view layout, as well as the creation of a ViewHolder, based on what type of object it is -- that will require that each distinct AbstractFormElement will have its own "view type", according to the Adapter. See BaseAdapter#getItemViewType(int) and related getViewTypeCount().
It's worth noting that these will need distinct view types only if one cannot be converted to the other... For example, if you have two "Elements" that only need to display a string of text in the list, those can both share a "text-only" view type. Likewise, two elements that only display a photo, or can easily convert one to the other (e.g., an icon with a caption, vs a photo thumbnail with no caption), can share a single "image-plus-caption" view type.
With the above in mind, you actually would end up having to modify different files to add a new type (well, I guess technically you could have them all in one file, as inner classes, but there's really no good argument for doing that), but if you've done your interface API correctly, and follow good OO practices, and implement good unit tests, you'll considerably reduce the amount of effort required to find bugs -- simply because most of the things involved in adding a new type would actually force a compiler error if you do it incorrectly. Add to that the fact that a proper unit test suite will be able to programmatically add all possible types, and ensure that everything displays properly, and you should have a pretty streamlined process for easy extensibility :)
It sounds like a lot of work, and it might seem tedious and verbose at first... But the end result is actually much more maintainable, especially if your list of element types is going to be fairly extensive.