Avoid Dependencies In a library: Android

When providing a library like a parser for location-based information one of the most important points is to not create any kind of dependency into the application which later uses the library.
But what does this mean? Here is a small example:
The application ApplA wants to get the location for a certain GPS position and store it into an ApplA.LocationObject, so a request to the library would look like this:

 

 

And here is the problem why this is not the right way to do it: If someone else wants to use the library in another application B, this application would need the ApplA.LocationObject which it will not have access to. So the developer of application B would need to change the library code to return a ApplB.LocationObject and this would have to be done every time the library is imported into a new application. Often it not even possible to change the library code because it’s wrapped in a non editable jar-file so another solution has to be found.
The most obvious solution would be to move the LocationObject class into the library and return a Library.LocationObj for the request. Then a developer would need to use this LocationObj in his or her application or the information would have to be extracted from the Library.LocationObj and stored in a ApplA.LocationObj. This solution is not very flexible and will force the developer to be dependant on the objects it gets from the library or convert them at least. He has to determine what is stored in the Library.LocationObj and how to get access to this information.
Lets take a step back to what the developer would really want to get. It is information about the location at a certain GPS position so how do we return this information and not a static object where the developer has to figure out how to use it and get to the information inside. The answer to this question is the listener concept and here is how it works:
The user will pass an additional object (the listener) when requesting the location for the GPS position, so it will look like this:

 








 

The library then has to call the onRecieveLocationInformation-method when the information is parsed. This way the ApplA.MyLocationObject now only has to implement the LocationListener interface and it will be notified by the library when the location information is received. It will get all the information about the location and can store these in its custom way.
The listener concept is a very powerful way to remove dependencies and this is only one of many scenarios where it can be used. There are a lot more benefits when using this concept, for example this way the request to the server could be done in a separate thread much easier because the code is no longer structured in a linear way.
Here is one more example how your code could look like, when using the listener concept:

 















 

So what do you think about this? Feel free to add some comments Open-mouthed smile

Random Name Generator: Android

Today i needed a name generator so i wrote one myself (i didn’t like the existing ones i found via Google. Here is the test code i used:

It produces names like:
Pausyp
Braurjnn
Thushoob
Einnjk
Qeidegh
Aub
Xoihut
Voopych
Gljint
Och
Stontaigh
Loofautt
Grennoogh
Jshjnt
Zjlouv
Fabeih
Aishof
Hoir
Ait
Jihoint
Aiv
Poim
Flott
Ustjv
Zjis
Xittoutt
I also added constructors for complete customization of the generate process. Here is the code:

 

Comment Please.Rolling on the floor laughing

10 Rules Every Android Programmer Should Know

I’ve now read a few interesting things that you should consider when programming Android in order to ensure as much performance as possible:

  1. As rarely as possible allocate memory
  2. Possible use etc but no integer int.
  3. Temporary return values ​​to avoid if possible! Strings that are used once and then return to the no longer needed brakes, the system unnecessarily. Rather the operation on the string to move the method itself.
  4. Multidimensional arrays can be simulated by one dimensional. Rumgetrickse for me a bit too much at the expense of readability ..
  5. Virtual methods instead of interface methods (eg, not using hashmap Map)
  6. Static methods are much faster than virtual
  7. no getter and setter
  8. Instead of access to member variables, they should only pass to a local.
  9. Do not use enums but constants for the elements of enums
  10. Avoid use of floating point numbers as floating-point arithmetic must be simulates cumbersome.

    One has therefore to ensure the performance of a piece of code readability, reduce and rewrite in a few years, the unreadable code again.

c7875ff7f880fe46f6b3067ecc30a41a-server-clip-art

The advantage of threading is the ability to create applications that use more than one thread of execution. For example, a process can have a user interface thread that manages interactions with the user and worker threads that perform other tasks while the user interface thread waits for user input.

This tutorial demonstrates various thread activities:

  • Creating and executing a thread
  • Synchronization of threads
  • Interaction between threads
  • Using a thread pool
  • Using a mutex object to protect a shared resource
  • See Threading Sample to download and build the sample files discussed in this tutorial.

    Sample Files

     

    Example 1: Creating, starting, and interacting between threads

    This example demonstrates how to create and start a thread, and shows the interaction between two threads running simultaneously within the same process. Note that you don’t have to stop or free the thread. This is done automatically by the .NET Framework common language runtime.

    The program begins by creating an object of type Alpha (oAlpha) and a thread (oThread) that references the Beta method of the Alpha class. The thread is then started. TheIsAlive property of the thread allows the program to wait until the thread is initialized (created, allocated, and so on). The main thread is accessed through Thread, and theSleep method tells the thread to give up its time slice and stop executing for a certain amount of milliseconds. The oThread is then stopped and joined. Joining a thread makes the main thread wait for it to die or for a specified time to expire (for more details, see Thread.Join Method). Finally, the program attempts to restart oThread, but fails because a thread cannot be restarted after it is stopped (aborted). For information on temporary cessation of execution, see Suspending Thread Execution.

    Example Output

    Example 2: Synchronizing two threads: a producer and a consumer

    The following example shows how synchronization can be accomplished using the C# lock keyword and the Pulse method of the Monitor object. The Pulse method notifies a thread in the waiting queue of a change in the object’s state (for more details on pulses, see the Monitor.Pulse Method).

    The example creates a Cell object that has two methods: ReadFromCell and WriteToCell. Two other objects are created from classes CellProd and CellCons; these objects both have a method ThreadRun whose job is to call ReadFromCell and WriteToCell. Synchronization is accomplished by waiting for “pulses” from the Monitor object, which come in order. That is, first an item is produced (the consumer at this point is waiting for a pulse), then a pulse occurs, then the consumer consumes the production (while the producer is waiting for a pulse), and so on.