ArcView Demo

A very simple arc layout library for Android

Include the ArcLayout widget in your layout

Download Source code

Java Memory Model

The Java memory model specifies how the Java virtual machine works with the computer's memory (RAM). The Java virtual machine is a model of a whole computer so this model naturally includes a memory model - AKA the Java memory model.

It is very important to understand the Java memory model if you want to design correctly behaving concurrent programs. The Java memory model specifies how and when different threads can see values written to shared variables by other threads, and how to synchronize access to shared variables when necessary.

The original Java memory model was insufficient, so the Java memory model was revised in Java 1.5. This version of the Java memory model is still in use in Java 8.

The Internal Java Memory Model

The Java memory model used internally in the JVM divides memory between thread stacks and the heap. This diagram illustrates the Java memory model from a logic perspective:

Each thread running in the Java virtual machine has its own thread stack. The thread stack contains information about what methods the thread has called to reach the current point of execution. I will refer to this as the "call stack". As the thread executes its code, the call stack changes.

The thread stack also contains all local variables for each method being executed (all methods on the call stack). A thread can only access it's own thread stack. Local variables created by a thread are invisible to all other threads than the thread who created it. Even if two threads are executing the exact same code, the two threads will still create the local variables of that code in each their own thread stack. Thus, each thread has its own version of each local variable.

All local variables of primitive types ( boolean, byte, short, char, int, long, float, double) are fully stored on the thread stack and are thus not visible to other threads. One thread may pass a copy of a pritimive variable to another thread, but it cannot share the primitive local variable itself.

The heap contains all objects created in your Java application, regardless of what thread created the object. This includes the object versions of the primitive types (e.g. Byte, Integer, Long etc.). It does not matter if an object was created and assigned to a local variable, or created as a member variable of another object, the object is still stored on the heap.

Here is a diagram illustrating the call stack and local variables stored on the thread stacks, and objects stored on the heap:

A local variable may be of a primitive type, in which case it is totally kept on the thread stack.

A local variable may also be a reference to an object. In that case the reference (the local variable) is stored on the thread stack, but the object itself if stored on the heap.

An object may contain methods and these methods may contain local variables. These local variables are also stored on the thread stack, even if the object the method belongs to is stored on the heap.

An object's member variables are stored on the heap along with the object itself. That is true both when the member variable is of a primitive type, and if it is a reference to an object.

Static class variables are also stored on the heap along with the class definition.

Objects on the heap can be accessed by all threads that have a reference to the object. When a thread has access to an object, it can also get access to that object's member variables. If two threads call a method on the same object at the same time, they will both have access to the object's member variables, but each thread will have its own copy of the local variables.

Here is a diagram illustrating the points above:

Two threads have a set of local variables. One of the local variables (Local Variable 2) point to a shared object on the heap (Object 3). The two threads each have a different reference to the same object. Their references are local variables and are thus stored in each thread's thread stack (on each). The two different references point to the same object on the heap, though.

Notice how the shared object (Object 3) has a reference to Object 2 and Object 4 as member variables (illustrated by the arrows from Object 3 to Object 2 and Object 4). Via these member variable references in Object 3 the two threads can access Object 2 and Object 4.

The diagram also shows a local variable which point to two different objects on the heap. In this case the references point to two different objects (Object 1 and Object 5), not the same object. In theory both threads could access both Object 1 and Object 5, if both threads had references to both objects. But in the diagram above each thread only has a reference to one of the two objects.

So, what kind of Java code could lead to the above memory graph? Well, code as simple as the code below:

public class MyRunnable implements Runnable() {

    public void run() {
        methodOne();
    }

    public void methodOne() {
        int localVariable1 = 45;

        MySharedObject localVariable2 =
            MySharedObject.sharedInstance;

        //... do more with local variables.

        methodTwo();
    }

    public void methodTwo() {
        Integer localVariable1 = new Integer(99);

        //... do more with local variable.
    }
}

public class MySharedObject {

    //static variable pointing to instance of MySharedObject

    public static final MySharedObject sharedInstance =
        new MySharedObject();


    //member variables pointing to two objects on the heap

    public Integer object2 = new Integer(22);
    public Integer object4 = new Integer(44);

    public long member1 = 12345;
    public long member1 = 67890;
}

If two threads were executing the run() method then the diagram shown earlier would be the outcome. The run() method calls methodOne() and methodOne() calls methodTwo().

methodOne() declares a primitive local variable (localVariable1 of type int) and an local variable which is an object reference (localVariable2).

Each thread executing methodOne() will create its own copy of localVariable1 and localVariable2 on their respective thread stacks. The localVariable1 variables will be completely separated from each other, only living on each thread's thread stack. One thread cannot see what changes another thread makes to its copy of localVariable1.

Each thread executing methodOne() will also create their own copy of localVariable2. However, the two different copies of localVariable2 both end up pointing to the same object on the heap. The code setslocalVariable2 to point to an object referenced by a static variable. There is only one copy of a static variable and this copy is stored on the heap. Thus, both of the two copies of localVariable2 end up pointing to the same instance of MySharedObject which the static variable points to. The MySharedObjectinstance is also stored on the heap. It corresponds to Object 3 in the diagram above.

Notice how the MySharedObject class contains two member variables too. The member variables themselves are stored on the heap along with the object. The two member variables point to two otherInteger objects. These Integer objects correspond to Object 2 and Object 4 in the diagram above.

Notice also how methodTwo() creates a local variable named localVariable1. This local variable is an object reference to an Integer object. The method sets the localVariable1 reference to point to a newInteger instance. The localVariable1 reference will be stored in one copy per thread executingmethodTwo(). The two Integer objects instantiated will be stored on the heap, but since the method creates a new Integer object every time the method is executed, two threads executing this method will create separate Integer instances. The Integer objects created inside methodTwo() correspond to Object 1 and Object 5 in the diagram above.

Notice also the two member variables in the class MySharedObject of type long which is a primitive type. Since these variables are member variables, they are still stored on the heap along with the object. Only local variables are stored on the thread stack.

Hardware Memory Architecture

Modern hardware memory architecture is somewhat different from the internal Java memory model. It is important to understand the hardware memory architecture too, to understand how the Java memory model works with it. This section describes the common hardware memory architecture, and a later section will describe how the Java memory model works with it.

Here is a simplified diagram of modern computer hardware architecture:

A modern computer often has 2 or more CPUs in it. Some of these CPUs may have multiple cores too. The point is, that on a modern computer with 2 or more CPUs it is possible to have more than one thread running simultaneously. Each CPU is capable of running one thread at any given time. That means that if your Java application is multithreaded, one thread per CPU may be running simultaneously (concurrently) inside your Java application.

Each CPU contains a set of registers which are essentially in-CPU memory. The CPU can perform operations much faster on these registers than it can perform on variables in main memory. That is because the CPU can access these registers much faster than it can access main memory.

Each CPU may also have a CPU cache memory layer. In fact, most modern CPUs have a cache memory layer of some size. The CPU can access its cache memory much faster than main memory, but typically not as fast as it can access its internal registers. So, the CPU cache memory is somewhere in between the speed of the internal registers and main memory. Some CPUs may have multiple cache layers (Level 1 and Level 2), but this is not so important to know to understand how the Java memory model interacts with memory. What matters is to know that CPUs can have a cache memory layer of some sort.

A computer also contains a main memory area (RAM). All CPUs can access the main memory. The main memory area is typically much bigger than the cache memories of the CPUs.

Typically, when a CPU needs to access main memory it will read part of main memory into its CPU cache. It may even read part of the cache into its internal registers and then perform operations on it. When the CPU needs to write the result back to main memory it will flush the value from its internal register to the cache memory, and at some point flush the value back to main memory.

The values stored in the cache memory is typically flushed back to main memory when the CPU needs to store something else in the cache memory. The CPU cache can have data written to part of its memory at a time, and flush part of its memory at a time. It does not have to read / write the full cache each time it is updated. Typically the cache is updated in smaller memory blocks called "cache lines". One or more cache lines may be read into the cache memory, and one or mor cache lines may be flushed back to main memory again.

Bridging The Gap Between The Java Memory Model And The Hardware Memory Architecture

As already mentioned, the Java memory model and the hardware memory architecture are different. The hardware memory architecture does not distinguish between thread stacks and heap. On the hardware, both the thread stack and the heap are located in main memory. Parts of the thread stacks and heap may sometimes be present in CPU caches and in internal CPU registers. This is illustrated in this diagram:

When objects and variables can be stored in various different memory areas in the computer, certain problems may occur. The two main problems are:

• Visibility of thread updates (writes) to shared variables.
• Race conditions when reading, checking and writing shared variables.

Both of these problems will be explained in the following sections.

Visibility of Shared Objects

If two or more threads are sharing an object, without the proper use of either volatile declarations or synchronization, updates to the shared object made by one thread may not be visible to other threads.

Imagine that the shared object is initially stored in main memory. A thread running on CPU one then reads the shared object into its CPU cache. There it makes a change to the shared object. As long as the CPU cache has not been flushed back to main memory, the changed version of the shared object is not visible to threads running on other CPUs. This way each thread may end up with its own copy of the shared object, each copy sitting in a different CPU cache.

The following diagram illustrates the sketched situation. One thread running on the left CPU copies the shared object into its CPU cache, and changes its count variable to 2. This change is not visible to other threads running on the right CPU, because the update to count has not been flushed back to main memory yet.

To solve this problem you can use Java's volatile keyword. The volatile keyword can make sure that a given variable is read directly from main memory, and always written back to main memory when updated.

Race Conditions

If two or more threads share an object, and more than one thread updates variables in that shared object,race conditions may occur.

Imagine if thread A reads the variable count of a shared object into its CPU cache. Imagine too, that thread B does the same, but into a different CPU cache. Now thread A adds one to count, and thread B does the same. Now var1 has been incremented two times, once in each CPU cache.

If these increments had been carried out sequentially, the variable count would be been incremented twice and had the original value + 2 written back to main memory.

However, the two increments have been carried out concurrently without proper synchronization. Regardless of which of thread A and B that writes its updated version of count back to main memory, the updated value will only be 1 higher than the original value, despite the two increments.

This diagram illustrates an occurrence of the problem with race conditions as described above:

Slide up down Demo Android

This library provides a simple way to add a draggable sliding up panel (popularized by Google Music and Google Maps) to your Android application.

Usage

• Include com.bdlibslidinguppanel.SlidingUpPanelLayout as the root element in your activity layout.
• The layout must have gravity set to either top or bottom.
• Make sure that it has two children. The first child is your main layout. The second child is your layout for the sliding up panel.
• The main layout should have the width and the height set to match_parent.
• The sliding layout should have the width set to match_parent and the height set to either match_parent, wrap_contentor the max desireable height. If you would like to define the height as the percetange of the screen, set it tomatch_parent and also define a layout_weight attribute for the sliding view.
• By default, the whole panel will act as a drag region and will intercept clicks and drag events. You can restrict the drag area to a specific view by using the setDragView method or umanoDragView attribute.

For more information, please refer to the sample code.

<com.sothree.slidinguppanel.SlidingUpPanelLayout
    xmlns:sothree="http://schemas.android.com/apk/res-auto"
    android:id="@+id/sliding_layout"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:gravity="bottom"
    sothree:umanoPanelHeight="68dp"
    sothree:umanoShadowHeight="4dp">

    <TextView
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        android:gravity="center"
        android:text="Main Content"
        android:textSize="16sp" />

    <TextView
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        android:gravity="center|top"
        android:text="The Awesome Sliding Up Panel"
        android:textSize="16sp" />
</com.sothree.slidinguppanel.SlidingUpPanelLayout>

For smooth interaction with the ActionBar, make sure that windowActionBarOverlay is set to true in your styles:

<style name="AppTheme">
    <item name="android:windowActionBarOverlay">true</item>
</style>

However, in this case you would likely want to add a top margin to your main layout of ?android:attr/actionBarSize or ?attr/actionBarSize to support older API versions.

Caveats, Additional Features and Customization

• If you are using a custom umanoDragView, the panel will pass through the click events to the main layout. Make your second layout clickable to prevent this.
• You can change the panel height by using the setPanelHeight method or umanoPanelHeight attribute.
• If you would like to hide the shadow above the sliding panel, set shadowHeight attribute to 0.
• Use setEnabled(false) to completely disable the sliding panel (including touch and programmatic sliding)
• Use setTouchEnabled(false) to disables panel's touch responsiveness (drag and click), you can still control the panel programatically
• Use getPanelState to get the current panel state
• Use setPanelState to set the current panel state
• You can add parallax to the main view by setting umanoParallaxOffset attribute (see demo for the example).
• You can set a anchor point in the middle of the screen using setAnchorPoint to allow an intermediate expanded state for the panel (similar to Google Maps).
• You can set a PanelSlideListener to monitor events about sliding panes.
• You can also make the panel slide from the top by changing the layout_gravity attribute of the layout to top.
• You can provide a scroll interpolator for the panel movement by setting umanoScrollInterpolator attribute. For instance, if you want a bounce or overshoot effect for the panel.
• By default, the panel pushes up the main content. You can make it overlay the main content by using setOverlayedmethod or umanoOverlay attribute. This is useful if you would like to make the sliding layout semi-transparent. You can also set umanoClipPanel to false to make the panel transparent in non-overlay mode.
• By default, the main content is dimmed as the panel slides up. You can change the dim color by changingumanoFadeColor. Set it to "@android:color/transparent" to remove dimming completely.

Scrollable Sliding Views

If you have a scrollable view inside of the sliding panel, make sure to set umanoScrollableView attribute on the panel to supported nested scrolling. The panel supports ListView, ScrollView and RecyclerView out of the box, but you can add support for any type of a scrollable view by setting a custom ScrollableViewHelper. Here is an example forNestedScrollView

public class NestedScrollableViewHelper extends ScrollableViewHelper {
  public int getScrollableViewScrollPosition(View scrollableView, boolean isSlidingUp) {
    if (mScrollableView instanceof NestedScrollView) {
      if(isSlidingUp){
        return mScrollableView.getScrollY();
      } else {
        NestedScrollView nsv = ((NestedScrollView) mScrollableView);
        View child = nsv.getChildAt(0);
        return (child.getBottom() - (nsv.getHeight() + nsv.getScrollY()));
      }
    } else {
      return 0;
    }
  }
}

Once you define your helper, you can set it using setScrollableViewHelper on the sliding panel.

\

Slide up menu 

Download Source Code :Slide up Menu

Easy Understand Activity life cycle

States of an activity

An activity can be in different states depending how it is interacting with the user. These states are described by the following table.

State	Description
Running	Activity is visible and interacts with the user.
Paused	Activity is still visible but partially obscured, instance is running but might be killed by the system.
Stopped	Activity is not visible, instance is running but might be killed by the system.
Killed	Activity has been terminated by the system of by a call to its finish() method.

The live cycle methods

The Android system defines a life-cycle for activities via predefined life-cycle methods. The most important methods are: .Important Activity lifecycle methods:

Method	Purpose
onCreate()	Called then the activity is created. Used to initialize the activity, for example create the user interface.
onResume()	Called if the activity get visible again and the user starts interacting with the activity again. Used to initialize fields, register listeners, bind to services, etc.
onPause()	Called once another activity gets into the foreground. Always called before the activity is not visible anymore. Used to release resources or save application data. For example you unregister listeners, intent receivers, unbind from services or remove system service listeners.
onStop()	Called once the activity is no longer visible. Time or CPU intensive shut-down operations, such as writing information to a database should be down in the onStop() method. This method is guaranteed to be called as of API 11.

Transfer apps to a different developer account

Review transfer tips & requirements

When you transfer apps to a different account, your apps' users, download statistics, ratings and reviews, content ratings, and store listing information are all transferred to your new account.Your bulk export reports, payout reports, and earnings reports won't transfer with the app, so you may want to download any reports you'll need later. New versions of these reports will be created once the app transfers to a new account.For our team to complete a transfer request, the original account and all apps being transferred need to comply with all policy guidelines.Our team can't transfer apps that offer subscription products.

Get ready to transfer apps

Step 1: Make sure your Google Play Developer accounts are registered & active

Before our team can transfer apps from your original account to a different account, known as your target account, both Google Play Developer accounts need to be fully registered and active.

Note: You need to pay the $25 USD registration fee for both accounts. After the transfer is complete, if you want to close your original account, our team can refund its registration fee.

Step 2: Transfer your developer name

If you want to use the same developer name on your target account as you're using on your original account, you need to change the name on your original account first.

Once you've changed your developer name on the original account, you can update the developer name on your target account.

Step 3: Find your account registration IDs

You'll need both of the transaction IDs for your original and target account registrations. You can find this on the receipt that was emailed to you when you registered for each account.

Tip: If you can't find them in your email, check your transactions on the account you used to pay the account registration fee.

Transactions IDs for registrations are typically in one of the following formats:

01234567890123456789.token.0123456789012345

0.G.123456789012345

registration-1234ab56-7c89-12d3-4567-8e91234567f8

Step 4: Prepare your target account

If you're transferring paid apps, apps with in-app products, or apps distributed on a private channel, there are a few steps you need to complete to prepare your target account.

If you're only transferring free apps and have completed the previous steps, move on to the next step.

Transfer paid apps or apps with in-app purchases

Transfer private channel apps (Google Apps accounts only):-

If you're using a Google Apps account (domain does not end with @gmail.com) to distribute apps internally to users in your organization using a private channel, here's how to prepare your account and apps.

Step 1: Prepare your target account

Your target account needs to belong to the same Google Apps domain as your original account.

For example, if your original account was developer@yourcompanyorname.com, your target account can be newdeveloper@yourcompanyorname.com.

Step 2: Prepare your apps

For each of your apps, you need to remove the restricted distribution setting and unpublish the app.

Sign in to your Google Play Developer Console.

Select an app.

On the left menu, click Pricing & Distribution.

Under "Restrict Distribution," uncheck "Only make this app available to users of my Google apps domain name."

Click Submit update > Unpublish app.

After we've transferred your app, you can restrict distribution and publish your app again on your private channel. Existing users are not affected during the transfer.

Step 5: Update accounts & apps that use integrated services

If you use any integrated services on your apps, including Google Analytics, Firebase, and Google Play game services, make sure to update your account settings and apps.

If you don't use any integrated services on your apps, move on to the next step to submit your transfer request.

Google Analytics: Add permissions for your target account to your Google Analytics account.

Google Developer Console projects: Add your target account as an Owner for your Google Developers Console projects. These projects can include Google+ sign-in, Google Play game services, and other Google APIs.

Firebase projects: Unlink any Firebase projects from the original Developer Console account and link the projects to the target account.

Ad SDK integrations (including AdMob): Once your apps have been transferred to your target account, to make sure ad traffic is credited to the correct account, all ad SDK integrations will need to be updated in your apps' APK files.

APK translations: If you have any translation projects in progress using Google Play's translation service, they need to be completed before your app(s) can be transferred.

Tip: If you need help transferring a game services project, contact our support team.

Step 6: Submit your transfer request[ useful ]

After you've completed the previous steps, you're ready to submit your transfer request.

To help expedite your transfer, make sure you have the following information ready to submit:

Developer name on your target account

Original account email address

Target account email address

Transaction ID for original account registration

Transaction ID for target account registration

Package names for all apps you want to transfer to your target account

If you're transferring paid apps or apps with in-app purchases, make sure your target account has an active Google Payments Merchant account.

Tansfer apps Account Request .Click..here