Qualcomm announces major workforce restructure alongside FY 2015 results

Qualcomm has been on top in the mobile processor space for a number of years now, powering everything from budget smartphones to high-end flagships. But this year the company has seen its revenue and operating income drop by around $1 billion, as some expected. This has caused Qualcomm to announce a major restructuring of the company that will see workforce layoffs of up to 15 percent.

Qualcomm is looking to make savings of around $1.1 billion over the next two years from the labor aspects of its restructure. As part of the plan, the company will reduce its temporary workforce, make cuts to engineering, and cut its number of offices. The company is also reducing investment outside of its core chip business by $300 million per year. Overall, Qualcomm wants to save $1.4 billion annually.

“While we are sharply focused on managing costs, we are not sacrificing the future for the present,” – CEO Steve Mollenkopf

In an interview following the announcement, CEO Steve Mollenkopf also talked about the rumored company split. Qualcomm is to undertake a “fresh review” of its corporate structure, to be completed by the end of 2015. He refused to talk about the issue in any further detail until the analysis has been completed. The company may split its chip and licensing businesses into two companies, if a good enough reason to do so can be found.

In terms of financial figures, revenue fell 14 percent from $6.8 billion to $5.8 billion. Operating income fell by a huge 40 percent and net income was also down 47 percent year over year.

The reasons for Qualcomm’s poor year are tricky to pinpoint exactly, as the company has been taking hits at both the high and low ends of the market. The loss of Samsung as a major customer this year, when the company opted for its own Exynos chip in the Galaxy S6, has likely been costly. Samsung has continued to see profits from its semiconductor business grow, due to its own products and orders from Apple.

Overheating issues with its Snapdragon 810 SoC have also probably impacted chip demand. The move over to 64-bit seemed to catch Qualcomm out, leaving it to quickly design a chip based on ARM’s reference CPU designs rather than its own custom 64-bit core, codenamed Kyro.

In the cost effective end of the market, the increasing quality and feature sets included in lower cost MediaTek and RockChip products have also begun squeezing Qualcomm’s chip business, with their lower margin business models. These alternative manufacturers are seeing big success in growing markets such as India and China.

“We are not going to withdraw from tiers [of the market].” – CEO Steve Mollenkopf

Other companies are also now more widely making use of their own modems, which has been cutting into another one of Qualcomm’s traditional revenue streams.

Qualcomm does have a few reasons to be positive though. The company will be moving over to 16nm FinFET production next year and should be using its own 64-bit cores in next year’s Snapdragon 820 SoC. The company is also at the forefront of 5G modem technology, which will be important in the coming years, and is looking for additional revenue streams in the budding Internet of Things markets.

Despite the restructure, Qualcomm is looking to spend more than $4 billion on R&D in the coming years. The next twelve months are going to be a tough transitional period.

New study finds that 70% of millenials are using early upgrades to get new devices

The arena of smartphones is invariably a young person’s game – while there’s no reason why you can’t teach an old dog new tricks, it’s this generation’s youth that are benefiting most from this mobile revolution. With that in mind, it should be no surprise to hear that 70% of millenials are using early upgrades to get new devices, which is the headline of a new study by SellCell who surveyed 1,000 millenials (people between the ages of 18-34) in the US. For those of you claiming bias between ecosystems, the survey included pretty much exactly half iOS and half Android users.

Other key findings from the survey include:

• 56% of millenials have owned at least 3 smartphones in the last 5 years.
• 12% of millenials have owned at least 5 smartphones in the last 5 years.
• 47% of millenials claim that wanting an early upgrade is so that they can be an early adopter.
• and 88% of millenials are interested in trading their phone for money.

Those are some pretty heavy statistics, but it really gives an insight as to what young people are thinking these days and you really get the feeling that it is this generation that is driving the smartphone industry the way it is going. I can absolutely relate to all these points, except the one about owning 5 phones in 5 years – all I know is I want to be paid what those kids are getting paid.

What do you think about the statistics in this survey? Let us know your thoughts in the comments below.

Source: SellCell

The post New study finds that 70% of millenials are using early upgrades to get new devices appeared first on AndroidSPIN.

Top rookie Android developer mistakes

Alper Çuğun

Android is a fantastic platform to develop for. Its development tools are free, easy to come by, and available for Windows, MAC and Linux computers. Android has excellent developer documentation, it is the dominant mobile operating system, and it is available on phones, tablets, watches, TVs and cars. Developing and publishing an Android app is also incredibly easy and straight forward, considering that there are multiple Android app stores available, unlike the single app store for iOS and Windows.

The Android platform has matured quite a lot since September 2008, when version 1.0 was released. The first version of the SDK was released in November 2007, using Eclipse IDE and the ADT plugin. The tools available to developers has grown in leaps and bounds, as has the API, and today, the preferred (and officially sanctioned) method is using the Android Studio IDE. Android Studio is based on the IntelliJ IDE, and is designed to ease android app development. It achieves this in many ways, a few of which include

• Tools to catch performance, compatibility and usability problems during design/development
• Ability to preview layout designs for multiple devices during design/development
• Support for Google Cloud Messaging and App Engine integration with an Android app
• Templates to create and manage android projects
• Templates to create and manage smartphone, tablet, watch, TV and Auto apps

and a whole lot more.

Android Studio has been designed to alert developers to issues with their code, and helps alert beginner coders to a lot of the most common errors they can make. But the IDE can only do so much to protect new (and sometimes even experienced) developers from themselves.

In this article, we discuss some of the most common mistakes made by a rookie Android developers, in no particular order. Even some experienced developers fall prey to some of these mistakes sometimes, so hopefully you will find this rundown useful. Let’s begin!

Using iOS design language

This is relatively (comparatively) rare, but many developers coming from an iOS background tend to design their apps like iOS apps, rather than like Android apps. Both platforms are incredibly similar, but awfully different. An Android app should fit in with the Android system of doing things, while an iOS app should fit in with the iOS way of doing things. If you intend to develop for the Android platform, you must read the Android design guidelines first. At the very least peruse the document, so that you have a general understanding of the Android ecosystem. You do not want to confuse users with a jarring interface, different from every other app they use daily. Differentiate your app with features and functionality, and personalize with colors and logos.

Not using Intents

Intents are a key part of the Android system. They are a means of requesting for data or an action from another app component (could be the same app, or another, completely different app). There are loads of actions your app might want to perform, and rather than re-implementing these actions, you simply ask the Android system to pick the best suited app for that task. For example, an app requires to pick a contact, with phone number, from the device. Rather than reading the contacts database, and implementing a List to show the user all contacts that have a phone number, and then implementing the logic to select a contact, an experienced developer would simply use the following code snippet

private void pickContact() 
    Intent pickContactIntent = new Intent(Intent.ACTION_PICK, ContactsContract.Contacts.CONTENT_URI);
    pickContactIntent.setType(ContactsContract.CommonDataKinds.Phone.CONTENT_TYPE);
    startActivityForResult(pickContactIntent, PICK_CONTACT_REQUEST);

There are a ton of actions that can be performed using Intents, including taking pictures/videos, sharing content, playing videos, setting reminders and alarms, and much more. Developers can even define their own filters for intents.

Not using fragments

During the dark days of Android development, before Honeycomb (Ice Cream Sandwich for phones), Android apps were built using only activities and services. After the great awakening, the concept of fragments was introduced to the API. A fragment is a mini activity, that can be embedded (and combined with other fragments) in an activity. This enables developers build UIs that able to easily adapt and switch between tablet and phone sized devices.

Developing for the current Android version

Android has a well discussed fragmentation problem. The current version of Android, as of writing, is Lollipop version 5.1.1. Lollipop version 5.0 was released on November 12 2014, and over eight months later, Lollipop adoption stands at a measly 12%. Android M, the next version of Android is already available to developers and beta testers, and it is expected to be released around November 2015. Each version of Android introduces new APIs and a rookie Android developer would be tempted to immediately use the new APIs for apps. Doing this would greatly reduce the number of potential users for your app.

An experienced Android developer, on the other hand, would check for the availability of the new APIs in the Android Support Library, and use that instead. The Android Support Library package is a set of code libraries that provide backward-compatible versions of Android framework APIs as well as features that are only available through the library APIs.

At the other extreme, be wary of attempting to support really old devices. Supporting devices with Ice Cream Sandwich and above covers close to 95% of all current android devices.

Developing for a single (or two) screen

There are literally thousands of different Android devices in the market today, with different screen sizes and resolutions, and app widgets scale and look different on devices. The Android design specs contains guidelines on best practices for designing layouts. When designing for Android, developers should use dp (density independent pixels) for specifying image and widget sizes, and sp (scaleable pixels) for fonts. Check out our previous articles on why you should test on a range of devices, and how to economically test your app on a range of devices.

Experienced Android developers will switch between preview devices in Android Studio during design/development. Rookie Android developers, on the other hand, are more likely to assume that since it works great on their Samsung Galaxy S6 and/or LG G4, it would look equally good on the Galaxy Ace 2 and Moto G (or vice versa).

Blocking the main (UI) thread

For every Android application, on launch, the system creates a thread of execution, called the main (or UI) thread. This thread is in charge of dispatching touch/tap events to the app widgets, drawing and updating widgets, and general interactions with the user. By default, all code executed by an app is executed on the main thread. This used to pose a problem – when long running operations are performed on this thread, the app appears to be frozen or hung. This was such a problem, especially with apps that attempted to fetch network resources, that on newer versions of Android, apps cannot make network calls on the main thread. Other possibly long running tasks that shouldn’t be performed on the main thread include

• Loading bitmaps
• Writing/Reading from database/file
• Complex calculations

Below is a sample code for downloading an image from a separate thread and displaying it in an ImageView in response to a click event.

public void onClick(View v) 
    new Thread(new Runnable() 
        public void run() 
            final Bitmap bitmap =
                    loadImageFromNetwork("http://example.com/image.png");
            mImageView.post(new Runnable() 
                public void run() 
                    mImageView.setImageBitmap(bitmap);
                
            );
        
    ).start();

An experienced developer never wants his app to appear to be frozen. Also, the Android system alerts users with an Application Not Responding (ANR) if the main thread is blocked for a given period (5 seconds for activities). For possible long running tasks, consider using an AsyncTask. Also, consider using a ProgressBar while your app is performing a background task.

Not reading the docs

The Android Developer website is a comprehensive and extensive resource for Android app design, development and distribution. There are guides, tutorials, best practices, guidelines, specifications as well as API documentation. The website is regularly updated, and every aspiring Android developer must have this as a top bookmark. In addition, rookie Android developers will benefit immensely from StackOverflow. StackOverflow is an online community of developers, where users ask questions regarding any programming issues/challenges they face, and other professionals answer these questions. Virtually every problem a new developer can run into has been experienced, asked and answered on StackOverflow.

Deeply nested view hierarchy

A common rookie mistake is assuming that using basic layout structures leads to efficient layouts. Actually, every widget and layout added to the app increases the time spent drawing the app layout. Particularly, using the layout_weight parameter can be quite expensive during rendering. It is better to use a single RelativeLayout, and align the widgets in relation to each other. A flat, shallow and wide layout performs better than a narrow and deep layout. The Lint tool, bundled with Android Studio, can help optimize app layout files by recommending actions such as

• Use compound drawables: A LinearLayout with a single ImageView and TextView will be more efficient as a single compound drawable
• Useless parent: A layout with children, but whose removal wouldn’t affect the final appearance
• Useless leaf: A layout with no children and no background
• Deep Layouts: The maximum nest depth is 10. Ideally, app layouts should be 2-3 levels deep

Misunderstanding bitmaps/images

Bitmaps and images can, and do, use significant memory resources. Most rookie Android developers run into the dreaded OutOfMemoryError when loading and/or displaying collections of images. Before an image is drawn on screen, it must first be loaded in memory. For example, loading a 2448×3264 ARGB_8888 image requires 4 * 2448 * 3264 bytes when loaded. That is about 32MB memory allocation needed for a single image. If the image ends up being displayed as on an ImageView that’s 200×200 pixels in size, the memory allocation needed is actually only 4 * 200 * 200 bytes (about 160KB). Loading the entire image, only to display it on a 200×200 widget just used almost 32MB memory space, rather that 160KB.

Experienced developers know to use Bitmap.createScaledBitmap() when loading Bitmaps. Also, a rookie Android developer would be tempted to load images in the main thread. Check out the Android developer page on displaying bitmaps efficiently.

Assuming mobile app equals small project

This is a mistake seen all too often from almost everyone except experienced Android developers, or those with an experience in software development. Many new and aspiring Android developers somehow think that the fact that they are building an app for mobile devices means that it is a small project that shouldn’t require much prior planning, or can be completed in a weekend of pizza and coffee fueled coding binge. This is horrendously far from reality. Android app development is no different from any other software development project, and requires specifications, schedules/timelines, bug tracking, and a release and maintenance plan.

Android Developer Newsletter

Do you want to know more? Subscribe to our Android Developer Newsletter. Just type in your email address below to get all the top developer news, tips & links once a week in your inbox:
Email:

PS. No spam, ever. Your email address will only ever be used for Android Dev Weekly.

Conclusion

Android development, much like software development, is a fun and rewarding pastime (or work, if you call it that). The above is a non exhaustive list of some common mistakes newbie Android developers tend to make. There is only one way to become an experienced Android developer, and that is to keep developing apps. Did we leave something out? What silly mistakes did you make when starting out? Holler in the comments, some of us might still be making those mistakes.