Showing posts with label Android. Show all posts
Showing posts with label Android. Show all posts

Tuesday, 8 January 2019

View animation Expand and Collapse - Android

This Post helps to animate the android views expand and collapse like Expandable list view.

Find below the code snippet.

ViewAnimationUtils.java







 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
import android.view.View;
import android.view.ViewGroup;
import android.view.animation.Animation;
import android.view.animation.Transformation;

public class ViewAnimationUtils {

    int animDuration = 600;
 
    public static void expand(final View view) {
        view.measure(ViewGroup.LayoutParams.MATCH_PARENT, ViewGroup.LayoutParams.WRAP_CONTENT);
        final int targtetHeight = view.getMeasuredHeight();
        view.getLayoutParams().height = 0;
        view.setVisibility(View.VISIBLE);
        Animation animation = new Animation() {
            @Override
            protected void applyTransformation(float interpolatedTime, Transformation t) {
                view.getLayoutParams().height = interpolatedTime == 1
                        ? ViewGroup.LayoutParams.WRAP_CONTENT
                        : (int) (targtetHeight * interpolatedTime);
                view.requestLayout();
            }

            @Override
            public boolean willChangeBounds() {
                return true;
            }
        };
        animation.setDuration(animDuration);
        view.startAnimation(animation);
    }

    public static void collapse(final View view) {
        final int initialHeight = view.getMeasuredHeight();
        Animation animation = new Animation() {
            @Override
            protected void applyTransformation(float interpolatedTime, Transformation t) {
                if (interpolatedTime == 1) {
                    view.setVisibility(View.GONE);
                } else {
                    view.getLayoutParams().height = initialHeight - (int) (initialHeight * interpolatedTime);
                    view.requestLayout();
                }
            }

            @Override
            public boolean willChangeBounds() {
                return true;
            }
        };
        animation.setDuration(animDuration);
        view.startAnimation(animation);
    }
}

Example
TextView description;
Button expand, collapse;
expand.setOnClickListener(new View.OnClickListener() {
 @Override
 public void onClick(View v) {
  ViewAnimationUtils.expand(description)
 }
});

collapse.setOnClickListener(new View.OnClickListener() {
 @Override
 public void onClick(View v) {
  ViewAnimationUtils.expand(description)
 }
});

Tuesday, 16 January 2018

Add/Remove View on the Top of Activity or Fragment Android


Add view on to the top of your activity or fragment i.e. in simple to add custom view above the AppCompact/Support Toolbar.

FrameLayout rootLayout = (FrameLayout) findViewById (android.R.id.content);
View v = View.inflate(this, R.layout.overlay_layout, rootLayout);

Then when you want to remove it, below use the below code snippet

FrameLayout rootLayout = (FrameLayout)findViewById(android.R.id.content);
rootLayout.removeViewAt(rootLayout.getChildCount()-1);


Happy Coding :-)

Monday, 2 October 2017

Android Resource Layout Sub-folder

Right now, we are probably storing every xml layout file inside the layout/ folder. It is feasible and simple to manage in small projects, but when i'm developing a large and heavy projects/products i.e. more .xml files, we feel difficult in search and finding the files and the things will get messy.

So, is there any way to solve this problem?

Yes, after a long search i found the plugin called "Android File Grouping Plugin" but this not gives me the expected solution, this virtually group the layout files into folder and this can visualized only in the android studio which need to be enabled with the plugin, as like as we have it in the XCode for iOS Projects.

Solution:
Hence after the deep dive into the gradle's ground and found the solution for the same without using any third-party plugins and therefore it also directly reflects on the code and folder hierarchy.

here its go like this, please keenly follow the steps

1. Prepare the folder structure in the below way,  inside the res folder, create your own directory and
inside those folders keep the root folder named as "layout" and then keep on adding your .xml files as to your convenient. For EG: In the below example, i have made the designed the Boarding and Dashboard, under to that created the layout as root directory, then added my .xml files.

res/
  layout/
    boarding/
      layout/
        onboarding_activity.xml
        onboarding_fragment_guest.xml
        onboarding_fragment_user.xml
    dashboard/
      layout/
        dashboard_activity.xml
        dashboard_details.xml

2. The trick is to use gradle’s ability to merge multiple resource folders and set the res/ folder as well as the nested subfolders in the sourceSets block.  The quirk is that you can’t declare a container resource folder before you declare that folder’s child resource folders. Below is the sourceSets block from the build.gradle file. Notice that the subfolders are declared first.

sourceSets {
        main {
            res.srcDirs = [
                    'src/main/res/layout/boarding',
                    'src/main/res/layout/dashboard',
                    'src/main/res/layout',
                    'src/main/res'
            ]
        }
    }

Friday, 12 May 2017

Google’s new Mobile OS Fuchsia, gonna completely replace Android in sometimes


Google’s Android platform is the most widely used mobile operating system in the world. In fact, it’s so popular right now that it’s beyond difficult to imagine a future without Android. Of course, people at one point felt the same way about early smartphone platforms like Symbian and BlackBerry OS, which have been almost completely wiped from the face of the Earth at this point. Some day, iOS and Android will be distant memories as well.

If there’s one thing companies like Nokia and BlackBerry taught us, it’s that companies at the top can only stay at the top if they’re constantly preparing for the future. So, rather than rest on its laurels and sit pretty while Android continues to dominate the smartphone market, Google is already hard at work on a fresh new mobile platform called Fuchsia, which may some day completely replace Android.

Dig Through:

I decided to dig through open source to examine the state of Google’s upcoming Fuchsia OS. For anyone unfamiliar, Fuchsia seems to be the replacement for both Android and Chrome OS. Fuchsia is the actual name of the operating system, while Magenta is the name of the kernel, or more correctly, the microkernel. Many of the architectural design decisions appear to have unsurprisingly been focused on creating a highly scalable platform. Google is unsurprisingly bringing up Fuchsia on a number of platforms, including the humble Intel NUC. ARM, x86, and MIPS bring-up is exactly what you would expect for an Android successor, and it also seems clear that this platform will run on Intel laptops. More on this later.

My best guess is that Android as an API and runtime will live on as a legacy environment within Fuchsia. That’s not to say that all development of Android would immediately stop, which seems extremely unlikely. But Google can’t push two UI APIs as equal app frameworks over the long term: Mojo is clearly the future.  Ah, but what is Mojo? Well it’s the new API for writing Fuchsia apps, and it comes from Chromium. Mojo was originally created to “extract a common platform out of Chrome's renderer and plugin processes that can support multiple types of sandboxed content.” It seems to have enabled Android apps in Chrome OS, and now it will serve an even more extensive role as the developer API for Fuchsia.

Programming Languages in role!

Mojo in Fuchsia features intriguingly extensive language support. C/C++, Dart, Go, Java, Python, and Rust all have bindings to Mojo. I am guessing that C/C++ is for native development, Go is for networking, Java is for Android(?), Python is for scripting, and Rust is for writing portions of the kernel. (Or perhaps Rust's usage is minimal, suggests a commenter on Hacker News.) Mixing and matching languages aside, the main UI API is based on, yes, Dart.  Flutter is an existing Google widget framework for apps written in Dart, and it has been repurposed to become the UI framework for Andromeda. Flutter includes a series of Material Design widgets and was engineered to render apps up to 120fps.* I imagine Andromeda’s standard UI components will look similar if not identical to those of Android. A physically based renderer, Escher, is apparently being used to render, well, material elements and shadows in a high quality manner.

I have very strong reservations about Dart as the language of the primary platform API, but it’s best to wait for the fully revealed details before forming an opinion. The reason for Dart is obvious, however: to enable a cross-platform app framework. The pitch will clearly be that developers can write a Flutter app once and have it run on Fuchsia (Google's Flutter SDK), Android, and iOS with minimal extra work, in theory. (Flutter does not target the web.) Even if Fuchsia is its full replacement, Android will be a separate developer target for many years given its gigantic installed base.

Fuchsia's actual app run-time is called Modular, “a post-API programming model that allows applications to cooperate in a shared context without the need to call each other's APIs directly." To do this it uses Mojo inter-process communication (IPC) messages, which are exchanged via low-level primitives in the form of message pipes (small amounts of data), data pipes (large amounts of data), and shared buffers.

I'm may not technically correct to explain, how the various languages interface over these IPC calls, and what exactly that enables. The IDL used is the Fuchsia Interface Description Language (FIDL), “an encoding format used to describe [Mojo] interfaces to be used on top of Magenta message pipes. They are the standard way applications talk to each other in Fuchsia.” Right now at least, only C/C++, Dart, and Go have supported bindings. Dart is thus the main platform language. (My understanding is that Go is not exactly ideal for writing UI apps.)

Courtesy: techspecs, bgr, flutter

Tuesday, 24 May 2016

Best Programming Languages You Should Learn To Boost Your Salary


Source: http://fossbytes.com/python-go-scala-learn-best-programming-languages-salary-boost/

The 2016 Workforce-Skill Preparedness Report of Pay-scale, a salary tracking site, is out with many interesting trends related to the current tech job scenario. The report outlines that Go, Scala, and Python, along with big data tech provide the highest boost in your paycheck. if you are willing to grab a big bite of salary boost by learning some new technology or programming language, we are here to help you.It’s a no hidden fact that the knowledge of big data skills is the most in-demand in the tech world.

Today, the job market is witnessing a paradigm shift and big data skills like Hadoop and Apache Spark, along with Python, Go, and Scala, are gaining high in highest paid lists.  Using its pay-tracking database, the same trend in IT and other industries has been observed by Pay-scale.

These results have been published recently in its 2016 Workforce-Skills Preparedness Report. Among the highest valued skills that provide the biggest pay boost, all are tech related. Out of such top nine skills, seven are directly related to the deep knowledge of programming languages, frameworks, and operating systems.

The biggest jump is provided by the functional programming language Scala with an average pay jump of 22.2 percent.  Google’s Go programming language followed Scala at the second place with a 20 percent pay boost.  While Python didn’t crack the top positions in this list, it had a prominent presence in Pay Scale's survey. Depending on the job titles, Python was found to provide a pay boost of up to 8-14 percent.

Here’s the list of top 9 technologies that provide the highest salary jump:


Sunday, 17 April 2016

DVM vs ART - Android

There are some major performance improvements that ART brings which were lacking in Dalvik. But every pros have some cons too. I will try to discuss both the advantages and disadvantages here.
Android 4.4 KitKat, Google decided to introduce a new way of executing apps on top of the Android operating system. Let's take a closer look at what this new runtime, called ART
ART is Google's 2-year-long ongoing secret project, which aims to boost the performance of our Android devices.
Android L (5.0) ART has been made as the default runtime (ART has completely replaced Dalvik).
ART (Android RunTime) is the next version of Dalvik. Dalvik is the runtime, bytecode, and VM used by the Android system for running Android applications.
Dalvik is based on JIT (just in time) compilation. It means that each time you run an app, the part of the code required for its execution is going to be translated (compiled) to machine code at that moment. As you progress through the app, additional code is going to be compiled and cached, so that the system can reuse the code while the app is running. Since JIT compiles only a part of the code, it has a smaller memory footprint and uses less physical space on the device.
ART vs Dalvik / AOT vs JIT
Advantages of ART over Dalvik:
  1. The apps launch speed is amazingly fast in case of ART since nothing is compiled at execution.
  2. Boot speed is faster than dalvik since nothing is execued from dalvik partition as in case of odexed ROM in dalvik
  3. Increases battery backup by reducing CPU work due to absence of compilation work on apps execution.
  4. Improved Garbage Collection (GC)
  5. And finally it is a great reward to developers because most of developers are worried that odexed ROMs are faster than deodexed ROMs but they will deodex their ROMs since they heavily theme it. In case of ART whether the ROM is odexed or deodexed it doesn't matter, it compiles the full code into machine language on installation of apps. so even deodexed ROMs are as fast as odexed in ART
Disadvantages of ART
  1. Since ART precompiles apps on installation, it takes 10-20% more space upon installation than dalvik.
  2. As dex bytecodes are converted to native machine code on installation itself, installation takes more time.
Install times on my Nexus 4, for one of our larger projects, jumped from ~17 s to ~25 s.
Dalvik vs. ART Benchmark Results (Android 4.4) : Linpack
Single Thread ---> Dalvik (135) ---> ART(149) ---> 10.93%
Multi- Thread ---> Dalvik (336) ---> ART(383) ---> 13.82%
1) Compilation Approach
This is by far the biggest advantage of ART over Dalvik. The old guy Dalvik used Just-In-Time (JIT) approach in which the compilation was done on demand. All the dex files were converted into their respective native representations only when it was needed.
But ART uses the Ahead-Of-Time (AOT) approach, in which the dex files were compiled before they were demanded. This itself massively improves the performance and battery life of any Android device.
For example
In case of Dalvik, whenever you touch an app icon to open it, the necessary dex files gets converted into their equivalent native codes. The app will only start working when this compilation is done. So, the app is unresponsive until this finishes.
Moreover, this process is repeated every single time you open an app wasting CPU cycles and valuable battery juice.
But in case of ART, whenever you install an app, all the dex files gets converted once and for all. So the installation takes some time and the app takes more space than in Dalvik, but the performance is massively improved and battery life is smartly conserved.

2) Boot Time

In case of Dalvik, the cache is built with time the device runs and apps are used as is indicated by the JIT approach. So the boot time is very fast.
But in case of ART, the cache is built during the first boot, so the boot time is considerably more in case of ART. You might see an "Optimizing apps" dialog box sometimes you boot.

3) Space Usage

The space used by apps being run on ART is much more than that of Dalvik. Like a 20 MB app on Dalvik, takes more than 35 MB on ART.
So if you are on a low storage device, then this can be a huge disadvantage for you.

4) ART is Damn Fast

As discussed above, ART is extremely fast and smooth. Apps are very snappy and responsive. Any comparison between Dalvik and ART, will surely make the ART device win by a significant margin.
ART is the answer to all those who argued that iOS is faster and smoother than Android and is also more battery efficient.

Thanks & Courtesy: 

Tuesday, 25 August 2015

How to learn Android App development in 30 days?


You need to study core Java before starting to enter into the android platform.

Try to learn core Java by 5 days

Once you learned Code java

Try the below link and learn it by 5 days
In this link they have explained about android development from the very basic things.

They have many tutorial application with perfect explanation. And it will be easy to understand.

Try below link and learn it by 5 days
This blog will be useful to learn material designs and advanced technologies like chat application to do web service etc..

To know about all android application development and android versions update see the below link
Study and workout the below mentioned widgets by 10 days
  1. Should know completely about RelativeLayout, LinearLayout and should know where to use it.
  2. RecyclerView (For list and grid).
  3. Fragment.
  4. Navigation Drawer, and TabLayout.
  5. Database (Sqlite, Try to use third party libraries ex. Realm).
  6. Retrofit, Volley, Picasso, Glide, ,Fresco, Butterknife.
  7. Material Designs.
  8. Google maps.
  9. Thread, Handler, Asynchronous task.
  10. FrameLayout, Table Layout.
  11. Intent, Types of Intent.
  12. Broadcast Receiver, Service, Content Provider
  13. Gradle.
That’s it, you can learn Android with in 25 days.

Thanks :)