Under the hood of UIView.

CALayers are simply classes representing a rectangle on the screen with visual content. Root layer of UIView.

CALayer properties = visual appearance, such as:

• The size and position of the layer;
• The layer’s background color;
• The contents of the layer;
• The corners of the layer;
• Shadow of the layer;
• Stroke around the edges of the layer;
• etc.

With CALayer you can:

1. Create some neat effects.

Example: Maybe you want to take an image, and put it in a white frame, and apply a shadow to it to make it look neat.

2. Create some neat animating effects.

Example: You could start your image out with rounded corners, tap a button, and have it animate the corners back out to straight.

The default layer class for a UIView is the plain-old CALayer class .But you can use one of the handy subclasses that are available, such as CAGradientLayer, CATextLayer, CAShapeLayer, and others.

CALayer

self.view.layer.backgroundColor = [UIColor orangeColor].CGColor;
self.view.layer.cornerRadius = 20.0;
self.view.layer.frame = CGRectInset(self.view.layer.frame, 20, 20);

Sublayer of CALayer

CALayer *sublayer = [CALayer layer];
sublayer.backgroundColor = [UIColor blueColor].CGColor;
sublayer.shadowOffset = CGSizeMake(0, 3);
sublayer.shadowRadius = 5.0;
sublayer.shadowColor = [UIColor blackColor].CGColor;
sublayer.shadowOpacity = 0.8;
sublayer.frame = CGRectMake(30, 30, 128, 192);
[self.view.layer addSublayer:sublayer];

Image Sublayer of CALayer

sublayer.contents = (id) [UIImage imageNamed:@"BattleMapSplashScreen.jpg"].CGImage;
sublayer.borderColor = [UIColor blackColor].CGColor;
sublayer.borderWidth = 2.0;

Rounded corner Image Sublayer of CALayer

CALayer *sublayer = [CALayer layer];
sublayer.backgroundColor = [UIColor blueColor].CGColor;
sublayer.shadowOffset = CGSizeMake(0, 3);
sublayer.shadowRadius = 5.0;
sublayer.shadowColor = [UIColor blackColor].CGColor;
sublayer.shadowOpacity = 0.8;
sublayer.frame = CGRectMake(30, 30, 128, 192);
sublayer.borderColor = [UIColor blackColor].CGColor;
sublayer.borderWidth = 2.0;
sublayer.cornerRadius = 10.0;
[self.view.layer addSublayer:sublayer];

CALayer *imageLayer = [CALayer layer];
imageLayer.frame = sublayer.bounds;
imageLayer.cornerRadius = 10.0;
imageLayer.contents = (id) [UIImage imageNamed:@"BattleMapSplashScreen.jpg"].CGImage;
imageLayer.masksToBounds = YES;
[sublayer addSublayer:imageLayer];

Thanks for reading this article. I hope that you have got something new for you. Be sure to click ❤ below to recommend this article if you found it helpful. It means a lot to me. It inspires me.

Feel free to ask me any questions. Lets become friends on Linkedin :)

The functions assert() and require() are used for check a condition.

Lets see what will be if the condition is false:

• assert(false) — compiles to 0xfe, which is an invalid opcode, using up all remaining gas, and reverting all changes.
• require(false) — compiles to 0xfed which is the REVERT opcode, meaning it will refund the remaining gas.

Due to this, there are some tips which can help you to make a decision.

1. Use assert() to:

• check for overflow/underflow
• check invariants
• validate contract state after making changes
• avoid conditions which should never, ever be possible.
• Generally, you should use assert less often
• Generally, it will be use towards the end of your function.

2. Use require() to:

• Validate user inputs
• Validate the response from an external contract (for example, require(external.send(amount)) )
• Validate state conditions prior to executing state changing operations, for example, in an owned contract situation
• Generally, you should use require more often
• Generally, it will be used towards the beginning of a function.

Thanks for reading this article. I hope that you have got something new for you. Be sure to click ❤ below to recommend this article if you found it helpful. It means a lot to me. It inspires me.

Feel free to ask me any questions. Lets become friends on Linkedin :)

On 28 May 2015 and on 22 August 2016 Android M(arshmallow) and Android N(ougat) showed themselves to this wonderful world and the developers got their hearts beating with a new speed because of new cool features that Google has given to them.

This article is for people who have just started to learn Android development, but who is already in that time when Android M and N have been announced. In the article I will tell you what are the AlarmManager, Service and BroadcastReceiver and how to make them work in a team, that can help you to manage repeating actions in your application. And also I will introduce you with a new features in Android M — Doze Mode and Android N — Direct Boot Mode and show how to use them to have all benefits from Google updates and how that was before.

Our task:

The simplest example. We have two places of data sources: server A which generates some data, server B where we want to send that data to mix it with another one. We have all APIs for using the data from the both sides. We need to create a synchronizer, which will send the data from place A to place B every day with a determined frequency.

To make that we need:

1. AlarmManager which will work every day on a determined time;
2. Service which will synchronize the data from A to B (lets call it SyncService);
3. BroadcastReceiver which will help us to manage some actions when the system was rebooted (lets call it BootCompletedBroadcast) and a Service which will be called from BroadcastReceiver to manage our alarm (lets call it BootCompletedService).

1. AlarmManager

AlarmManager provides access to the system alarm services. These allow to schedule the application to be run at some point in the future.

First of all we should create an AlarmManager.

AlarmManager alarmManager = (AlarmManager)    context.getSystemService(Context.ALARM_SERVICE);

Then we declare a new Intent which will execute our service for synchronizing the data and wrap it in a new PendingIntent.

An Intent is an abstract description of an operation to be performed. It is an abstract representation of an action . By using the Intent class we, for example, start activities within a application, or communicate with components defined by the Android system (Activity, Service, ContentProvider, BroadcastReceiver).

A PendingIntent is a wrapper, which allows the another application to execute some code of our own application with the permissions of our application. Some code here means our intent.

private static final int RQ_SYNC_SERVICE = 1101;

Intent intent = new Intent(context, SyncService.class);
PendingIntent pendingIntent = PendingIntent.getService(context, RQ_SYNC_SERVICE, intent, 0);

Finally we have come to the most interesting part of the AlarmManager. There are different variants to set an alarm. For our purpose was chosen only 3 and I will explain you why.

1. void set (int type, long triggerAtMillis, PendingIntent operation) ordinary method to set the alarm added in API level 1. BUT! The world isn’t interesting if all work so easy. The method set(int, long, PendingIntent) works like a charm and does its main job only before the API 19. Be sure if the application’s targetSdkVersion is below API 19, all of its scheduled alarms will be treated as exact. Beginning in API 19, the trigger time passed to this method is treated as inexact: the alarm will not be delivered before this time, but may be deferred and delivered some time later.
2. void setExact (int type, long triggerAtMillis, PendingIntent operation) new method to set the alarm added in API level 19. It doesn’t permit the OS to adjust the delivery time. The alarm will be delivered as nearly as possible to the requested trigger time.
3. void setExactAndAllowWhileIdle (int type, long triggerAtMillis, PendingIntent operation) another method to set the alarm added in API level 23. It is like setExact (int, long, PendingIntent), but this alarm will be allowed to execute even when the system is in low-power idle modes. But what is the low-power idle mode? One of the new features of Android M is Doze Mode. This mode means that then the device lays without moving and without charging, after an hour it goes into Doze Mode — shutdown mode, when almost all applications stop using battery, they sleep. But don’t worry, when the user takes the device in his hands all applications wake up. So, to allow our alarm to execute exactly in time on Android M, we use the method setExactAndAllowWhileIdle (int, long, PendingIntent).

And now here is my “lovely” if-else-if-else (joke):

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
     alarmManager.setAndAllowWhileIdle(AlarmManager.RTC_WAKEUP,  targetTime, pendingIntent);
} 
else if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
     alarmManager.setExact(AlarmManager.RTC_WAKEUP, frequency, pendingIntent);
} 
else {
     alarmManager.set(AlarmManager.RTC_WAKEUP, frequency, pendingIntent);
}

But you can simplify the code by removing set(int, long, PendingIntent), all will work as expected.

2. Service

There are two types of services in Android which can help us to achieve the goal: IntentService and Service. Some words about their differences.

When to use

• The Service can be used in tasks with no UI, but shouldn’t be too long.
• The IntentService can be used in long tasks usually with no communication to Main Thread. Another case of use is when callbacks are needed (Intent triggered tasks).

Runs On

• The Service runs in background but it runs on the Main Thread of an application.
• The IntentService runs on a separate worker thread.

Limitations / Drawbacks

• The Service may block the Main Thread of an application.
• The IntentService cannot run tasks in parallel. Hence all the consecutive intents will go into the message queue for the worker thread and will execute sequentially.

So for our task, we have chosen an IntentService, because it is used for long tasks and works in a separate thread. The simplest IntentService looks like this:

public class SyncService extends IntentService {
    public SyncService() {
        super("SyncService");
    }

    @Override
    protected void onHandleIntent(@Nullable Intent intent) {
       // the code which will be executed when the service starts
    }
}

Don’t forget to register the service in the AndroidManifest.xml:

<service
    android:name=".service.SyncService"
    android:enabled="true"
    android:exported="false"
    android:process=":remote"/>

3. BroadcastReceiver

A BroadcastReceiver is an Android component which allows to register for system or application events. All registered receivers for an event are notified by the Android runtime once this event happens. For example, applications can register for the ACTION_BOOT_COMPLETED system event which is fired once the Android system has completed the boot process.

So the simplest BroadcastReceiver looks like this:

public class BootCompletedBroadcast extends BroadcastReceiver {
    @Override
    public void onReceive(Context context, Intent intent) {
        Intent i = new Intent(context, BootCompletedService.class);
        context.startService(i);
    }
}

Also we need to register the BroadcastReceiver in the AndroidManifest.xml and add the permission RECEIVE_BOOT_COMPLETED:

<manifest>
...
<uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED"/>
...
<application>
...
<receiver
    android:name=".service.BootCompletedBroadcast"
    android:directBootAware="true"
    android:enabled="true"
    android:exported="true">
    <intent-filter>
        <action android:name="android.intent.action.BOOT_COMPLETED"/>
        <action android:name="android.intent.action.LOCKED_BOOT_COMPLETED"/>
    </intent-filter>
</receiver>
</application>
</manifest>

Keep attention, please! Now i am going to speak about Android N new feature that should know everybody to make the code works properly.

There is a problem (or a feature) on the Android devices when it reboots, which causes the device’s storage to be encrypted until the user enters his credentials. Applications can’t function normally until the device is decrypted, so at this point the device can’t perform essential tasks such as receiving incoming calls, emails or messages. It also means applications can’t deliver notifications, or act on scheduled alarms . This means that applications that schedule alarms, or provide important and timely notifications, can’t run. This problem Android N solves with the introduction of Direct Boot mode.

Direct Boot is, essentially, the new name for that strange no-man’s land where the device has finished rebooting but isn’t fully initialized yet. Direct Boot mode allows applications to perform limited tasks and access specific sections of data, even when the device is encrypted.

To make the application work properly and use a new feature from Android N for getting notifications or alarms in Direct Boot mode, we set an attribute directBootAware to be true in the BroadcastReceiver.

android:directBootAware="true"

And add a new flag LOCKED_BOOT_COMPLETED, which works in a Direct Boot mode. On pre Android N devices we still use BOOT_COMPLETED to get rebooting action.

<action android:name="android.intent.action.BOOT_COMPLETED"/>
<action android:name="android.intent.action.LOCKED_BOOT_COMPLETED"/>

And the service which will be called from BroadcastReceiver to manage our alarm looks like this:

public class BootCompletedService extends IntentService {
    public BootCompletedService(String name) {
        super("BootCompleted");
    }

    @Override
    protected void onHandleIntent(@Nullable Intent intent) {
        // register our alarm again because rebooting has canceled it
    }
}

Conclusion

In this article we have learnt what is a chain AlarmManager — Service — BroadcastReceiver and where we can use it. Also we have told about new features from Android M — Doze Mode and from Android N — Direct Boot Mode and how to make them bring us all benefits from Google updates.

Thanks for reading this article. I hope that you have got something new for you. Be sure to click ❤ below to recommend this article if you found it helpful. It means a lot to me. It inspires me.

Feel free to ask me any questions. Lets become friends on Linkedin :)