As  I wrote in the UX with Wifi Direct: The connection acceptance dialog article, there is acceptance dialog, which requires User interaction before any data can be exchanged between the devices.

This is not really ideal situation with Thali project, in which we would actually require the connections do be established fully automatically.  To fix this I would have two solutions which might work, depending on requirements:

1. Teach each device, all “Known groups”, so they never ask for the dialog again
2. Modify the communications to be handled in a way that no dialogs are ever shown.

For the first fix, we could make an app, which you would start and select which mode it would work (either Advertiser who waits for connections, or a devise that initiates the connecting  process), and the app would then do connection and once its verified to work be exchanging some data, they would revert the roles and do new round. While running both devices should have the dialog shown once, and user would then need to click the accept button to store the information in “Known Groups” settings.

This of course would be required to be handled with each device we can potentially have connections between, and would need to be re-done , in case the device is cleaned.

The second fix would require doing the connection a bit differently, in essence the steps are:

1.  Use createGroup() fucntion from WifiP2pManager to create a group. This creates an access point, with random SSID and password.
   • Start same time a server which accepts the incoming connections required for your service
2.  Once the access point is ready, you’ll receive WIFI_P2P_CONNECTION_CHANGED_ACTION. Then fetch the group information to get the SSID & password
3. Create local service to advertise the access point. You can use the local instance variable for giving the access point information (SSID, password & IP-Address)
4. Do Service Discovery to find any peers nearby advertising their access points. Once found, see what SSID, password and IP-Address are used with there.
5.  Use WifiManager for forming the connection (instead of WifiP2pManager )
6. Once the Connection is established,
   1. Stop advertising for the access point.
   2. Remove the access point
   3. Stop searching for additional access points
7. Make connection to the IP-Address you got from the service you discovered in step 4.

Here’s coupld of pointers to remember with this approach

• Its likely that all devices get same IP address when they form the access point, and thus do remember to remove the access point in step 6, otherwise you’ll communicate with your own server in step 7.
• With Android devices, you can have connection only to one WLAN Access point, thus if you had any active WLAN connections, they will be disconnected when you start connecting in step 5.

I made simple example showing how the fix number two works, and you can find it from Github under the DrJukka/MyWifiMesh. Do note that its not fully finalized, and is just used for proof of concept for further development.

Wi-Fi Direct (formerly Wi-Fi P2P) is appearing in more and more smartphones these days and despite not having used it so far for anything useful I thought I’d investigate a bit more to see how it works and how it differs from Bluetooth in addition to the obviously higher data transfer rates.

Unlike many other Wi-Fi functionalities, Wi-Fi Direct is not specified by the IEEE. Instead, the Wi-Fi Alliance, best known for it’s Wi-Fi certification program and logo, was responsible for the feature. It’s not their first one, they were also the driving force to fix the WEP encryption issue many years ago with WPA and later WPA2. Also, they have defined the set of rules for Wireless Multi Media (WMM) and other options in the IEEE standards to ensure the implementation of a minimum set of features and interoperability between devices.

In essense the Wi-Fi direct feature is straight forward. While traditional Wi-Fi networks require an access point for devices to communicate with each other, Wi-Fi direct allows two devices to communicate with each other without a dedicated access point. Instead, one of the two devices assumes the role of the access point and becomes the Group Owner (GO) of the Wi-Fi direct network. Other devices, even non-Wi-Fi direct devices, can then join this group as the GO behaves just like a standard access point.  This means that the GO device also includes DHCP functionality to assign IP addresses to clients of the group network.

Once the Wi-Fi connection is established and an IP address has been assigned the standard TCP/IP protocol stack is used to transfer data between devices. And this is the biggest difference between Bluetooth and Wi-Fi direct. While Bluetooth defines profiles for transferring images, business cards, calendar entries, audio signals, etc., Wi-Fi direct itself only offers a transparent IP channel. To transfer data between two devices, compatible apps are required.

The advantage of this approach is that those apps can work in Wi-Fi direct networks and also in traditional Wi-Fi environments. A TV, for example, that is capable of traditional Wi-Fi and Wi-Fi direct can run a server application to receive pictures and video streams over both Wi-Fi variants. The home owner would stream his material over the traditional Wi-Fi network while visitors would use Wi-Fi direct to skip the somewhat complicated process of joining the local wireless infrastructure network.

The disadvantage of this approach in the example above is that the visitor has to first download a client app that can communicate with the server app on the television. While this might be acceptable for the scenario above, it’s too complicated for just exchanging a few images, files or contacts on the go between two smartphones. Perhaps Google will add such apps to Android in the future to make this easier but this wouldn’t help transferring files to the iPhone, Blackberries, Windows Phone, etc. This is where Bluetooth still shines due to its standardized profiles which are implemented on many operating systems. This is a bit unfortunate as transferring multimedia content between different mobile operating systems would definitely benefit from fast Wi-Fi transmissions due to ever increasing file sizes and the practical transfer speeds of Bluetooth of only around 2 Mbit/s.

In practice, Wi-Fi direct has arrived in Android smartphones today but is not really noticed so far. The Android OS offers an API for apps from version 4 of the OS to scan for Wi-Fi direct devices and then to establish a connection. That offers interesting possibilities for ad-hoc communication, such as for example local multi-player games. Think kids in cars on a long road trip…

In short, a Service is a broader implementation for the developer to set up background operations, while an IntentService is useful for “fire and forget” operations, taking care of background Thread creation and cleanup.

From the docs:

Service A Service is an application component representing either an application’s desire to perform a longer-running operation while not interacting with the user or to supply functionality for other applications to use.

IntentService IntentService is a base class for Services that handle asynchronous requests(expressed as Intents) on demand. Clients send requests through startService(Intent) calls; the service is started as needed, handles each Intent in turn using a worker thread, and stops itself when it runs out of work.

When to use?

• The Service can be used in tasks with no UI, but shouldn’t be too long. If you need to perform long tasks, you must use threads within Service.
• The IntentService can be used in long tasks usually with no communication to Main Thread. If communication is required, can use Main Thread handler or broadcast intents. Another case of use is when callbacks are needed (Intent triggered tasks).

How to trigger?

• The Service is triggered by calling method startService().
• The IntentService is triggered using an Intent, it spawns a new worker thread and the method onHandleIntent() is called on this thread.

Triggered From

• The Service and IntentService may be triggered from any thread, activity or other application component.

Runs On

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

Limitations / Drawbacks

• The Service may block the Main Thread of the 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.

When to stop?

• If you implement a Service, it is your responsibility to stop the service when its work is done, by calling stopSelf() or stopService(). (If you only want to provide binding, you don’t need to implement this method).
• The IntentService stops the service after all start requests have been handled, so you never have to call stopSelf().

使用Wi-Fi Direct技术可以让具备硬件支持的设备在没有中间接入点的情况下进行直接互联。Android 4.0（API版本14）及以后的系统都提供了对Wi-Fi Direct的API支持。通过对这些API的使用，开发者可以实现支持Wi-Fi Direct的设备间进行相互探测和连接，从而获得较之蓝牙更远距离的高速数据通信效果。对于诸如多人游戏、图片共享等需要在用户之间传输数据的应用而言，这一技术无疑是十分有价值的。
关于Wi-Fi Direct的API函数的使用需要注意一下几个要点：
·用于探测（discover）对等设备（peers）、向对等设备发起请求（request）以及建立连接（connect）的方法定义在类WifiP2pManager中。
·通过设置监听器（Listener）可以获知WifiP2pManager中方法调用的成功与否。监听器以参数的形式传递给被调用的方法。
·当发现新对等设备或链接丢失的时候，Wi-Fi Direct系统（framework）以意向（Intent）的方式根据检测到的不同事件做出相应的通知。
开发中，以上三点的配合使用相当普遍。简单举个例子，定义一个监听器WifiP2pManager.ActionListener并调用函数discoverPeers()，当相应事件发生的时候就会在ActionListener.onSuccess()和ActionListener.onFailure()两个方法中得到通知。当discoverPeers()方法检测到了对等设备列表变化的时候，可以收到由系统广播（broadcast）发出一个WIFI_P2P_PEERS_CHANGED_ACTION意向。
创建广播接收器以处理Wi-Fi Direct意向的基本步骤如下：
1、创建一个继承BroadcastReceiver类的新类。构造函数的参数分别传递WifiP2pManager,WifiP2pManager.Channel，以及在这个广播接收器中需要注册的活动（activity）。这是一种最常见的参数设置模式，它让广播接收器能够引起活动作出更新，同时又能在必要时使用Wi-Fi硬件和通信信道。
2、在广播接收器的onReceive()函数中，针对感兴趣的特定意向可以执行相应的动作（actions）。例如，当广播接收器收到了意向WIFI_P2P_PEERS_CHANGED_ACTION，就可以调用requestPeers()方法来列举出当前探测到的对等设备。
创建Wi-Fi Direct应用：
完整的Wi-Fi Direct应用包含创建并注册广播接收器、检测对等设备、连接对等设备以及在对等设备间传输数据几个方面的功能。下面将详细介绍如何实现。
准备工作：
在使用Wi-Fi Direct API之前，首先要确保应用程序能够访问硬件，并且设备支持Wi-Fi Direct协议。如果这些条件都满足，就可以获取一个WifiP2pManager实例，创建并注册广播接收器，最后就是使用Wi-Fi Direct API了。
在Android manifest文件中加入以下内容，允许使用Wi-Fi设备上的硬件并声明应用程序正确支持了调用API所需的最低SDK版本。
<uses-sdk android:minSdkVersion=”14″ />
<uses-permission android:name=”android.permission.ACCESS_WIFI_STATE” />
<uses-permission android:name=”android.permission.CHANGE_WIFI_STATE” />
<uses-permission android:name=”android.permission.CHANGE_NETWORK_STATE” />
<uses-permission android:name=”android.permission.INTERNET” />
<uses-permission android:name=”android.permission.ACCESS_NETWORK_STATE” />
检查Wi-Fi Direct支持并已开启。推荐在广播接收器收到WIFI_P2P_STATE_CHANGED_ACTION意向的时候进行检测。检测结果需要通告相应的活动并做出处理：
@Override
public void onReceive(Context context, Intent intent) {
…
String action = intent.getAction();
if (WifiP2pManager.WIFI_P2P_STATE_CHANGED_ACTION.equals(action)) {
int state = intent.getIntExtra(WifiP2pManager.EXTRA_WIFI_STATE, -1);
if (state == WifiP2pManager.WIFI_P2P_STATE_ENABLED) {
// Wifi Direct is enabled
} else {
// Wi-Fi Direct is not enabled
}
}
…
}
在活动的onCreate()方法中获取WifiP2pManager对象的一个实例，通过该对象的initialize()方法向Wi-Fi Direct系统注册当前的应用程序。注册成功后，会返回一个WifiP2pManager.Channel，通过它，应用程序就能和Wi-Fi Direct系统交互。WifiP2pManager和WifiP2pManager.Channel对象以及一个活动的引用最后都被作为参数传递给自定义的广播接收器。这样，该活动就能够响应广播接收器的通知并作出相应的更新。当然，这样做也使程序具备了操纵设备Wi-Fi状态的能力：
WifiP2pManager mManager;
Channel mChannel;
BroadcastReceiver mReceiver;
……
@Override
protected void onCreate(Bundle savedInstanceState){
…
mManager = (WifiP2pManager) getSystemService(Context.WIFI_P2P_SERVICE);
mChannel = mManager.initialize(this, getMainLooper(), null);
mReceiver = new WiFiDirectBroadcastReceiver(mManager, mChannel, this);
…
}
创建一个意向过滤器（intent filter），其中添加的意向种类和广播接收器中的保持一致：
IntentFilter mIntentFilter;
……
@Override
protected void onCreate(Bundle savedInstanceState){
……
mIntentFilter = new IntentFilter();
mIntentFilter.addAction(WifiP2pManager.WIFI_P2P_STATE_CHANGED_ACTION);
mIntentFilter.addAction(WifiP2pManager.WIFI_P2P_PEERS_CHANGED_ACTION);
mIntentFilter.addAction(WifiP2pManager.WIFI_P2P_CONNECTION_CHANGED_ACTION);
mIntentFilter.addAction(WifiP2pManager.WIFI_P2P_THIS_DEVICE_CHANGED_ACTION);
……
}
在活动的onResume()方法中注册广播接收器，并在活动的onPause()方法中注销它：
/* register the broadcast receiver with the intent values to be matched */
@Override
protected void onResume() {
super.onResume();
registerReceiver(mReceiver, mIntentFilter);
}
/* unregister the broadcast receiver */
@Override
protected void onPause() {
super.onPause();
unregisterReceiver(mReceiver);
}
一旦成功获取WifiP2pManager.Channel并创建了广播接收器，应用程序就已经具备了使用Wi-Fi Direct相关函数和接收Wi-Fi Direct意向的能力。尽管放手使用WifiP2pManager为你提供的方法，让程序也拥有Wi-Fi Direct的特殊能力吧！
探测对等设备（Discovering peers）
调用discoverPeers()函数可以探测到有效距离内的对等设备。它是一个异步函数，调用成功与否会在程序所创建WifiP2pManager.ActionListener监听器的onSuccess()和onFailure()中给出通知。值得注意的是，onSuccess()方法只会对成功探测到对等设备这一事件做出通知，而并不会提供任何关于已发现的对等设备的具体信息：
manager.discoverPeers(channel, new WifiP2pManager.ActionListener() {
@Override
public void onSuccess() {
…
}
@Override
public void onFailure(int reasonCode) {
…
}
});
当成功检测到对等设备存在的时候，系统会广播WIFI_P2P_PEERS_CHANGED_ACTION意向。程序接收到该意向后，通过调用requestPeers()方法，就能获得已经探测到对等设备的清单。下面代码将展示如何实现这一过程：
PeerListListener myPeerListListener;
……
if (WifiP2pManager.WIFI_P2P_PEERS_CHANGED_ACTION.equals(action)) {
/* request available peers from the wifi p2p manager. This is an asynchronous call and the calling activity is notified with a callback on PeerListListener.onPeersAvailable()  */
if (manager != null) {
manager.requestPeers(channel, myPeerListListener);
}
}
requestPeers()方法同样是一个异步函数，当它准备好一份对等设备列表的时候，就会通知监听器WifiP2pManager.PeerListListener中定义的onPeersAvailable()方法。而onPeersAvailable()方法中所能获取到的对等设备列表以WifiP2pDeviceList形式存储，通过遍历这个列表可以选择出希望连接的设备。
连接对等设备（Connecting to peers）
确定了要连接的设备，还需调用connect()方法建立连接。该方法的其中一个参数是WifiP2pConfig对象，它提供了要连接设备的相关信息。连接的成功与否需要通过监听器WifiP2pManager.ActionListener获取通知。下面的代码将示范如何建立设备连接：
//obtain a peer from the WifiP2pDeviceList
WifiP2pDevice device;
WifiP2pConfig config = new WifiP2pConfig();
config.deviceAddress = device.deviceAddress;
manager.connect(channel, config, new ActionListener() {
@Override
public void onSuccess() {
//success logic
}
@Override
public void onFailure(int reason) {
//failure logic
}
});
传输数据（Transferring data）
连接一旦建立成功，数据传输也就是顺理成章的事情。以下是通过socket发送数据的基本步骤：
1、创建ServerSocket。它将被用于监听特定端口，等待客户端发起的连接请求。该操作需要在后台线程中实现。
2、创建客户端Socket。客户端通过ServerSocket对应的IP和端口连接到服务设备。
3、客户端向服务器发生数据。客户socket成功连接到服务socket后，就能以字节流的形式向服务器发生数据了。
4、服务器socket通过accept()方法等待客户端数据连接的到来。该方法在收到客户端数据之前一直处于阻塞状态。因此，需要在单独的线程中调用它。数据连接一旦建立，服务设备就能接收到客户端的数据。这时要做的就是施以相应的动作，例如将数据保存到文件，或者是直接显示到用户界面上，等等。
以下代码修改自SDK自带的示例Wi-Fi Direct Demo。它演示了如何建立一对客户端-服务器连接，并由客户端向服务器发送JPEG图片。若需完整的演示工程，只需编译并运行SDK示例Wi-Fi Direct Demo即可。
public static class FileServerAsyncTask extends AsyncTask {
private Context context;
private TextView statusText;
public FileServerAsyncTask(Context context, View statusText) {
this.context = context;
this.statusText = (TextView) statusText;
}
@Override
protected String doInBackground(Void… params) {
try {
/* Create a server socket and wait for client connections. This call blocks until a connection is accepted from a client */
ServerSocket serverSocket = new ServerSocket(8888);
Socket client = serverSocket.accept();
/*If this code is reached, a client has connected and transferred data Save the input stream from the client as a JPEG file */
final File f = new File(Environment.getExternalStorageDirectory() + “/”
+ context.getPackageName() + “/wifip2pshared-”
+ System.currentTimeMillis()  + “.jpg”);
File dirs = new File(f.getParent());
if (!dirs.exists())
dirs.mkdirs();
f.createNewFile();
InputStream inputstream = client.getInputStream();
copyFile(inputstream, new FileOutputStream(f));
serverSocket.close();
return f.getAbsolutePath();
} catch (IOException e) {
Log.e(WiFiDirectActivity.TAG, e.getMessage());
return null;
}
}
// Start activity that can handle the JPEG image
@Override
protected void onPostExecute(String result) {
if (result != null) {
statusText.setText(“File copied – ” + result);
Intent intent = new Intent();
intent.setAction(android.content.Intent.ACTION_VIEW);
intent.setDataAndType(Uri.parse(“file://” + result), “image/*”);
context.startActivity(intent);
}
}
}
On the client, connect to the server socket with a client socket and transfer data. This example transfers a JPEG file on the client device’s file system：
Context context = this.getApplicationContext();
String host;
int port;
int len;
Socket socket = new Socket();
byte buf[]  = new byte[1024];
…
try {
/* Create a client socket with the host,  port, and timeout information.*/
socket.bind(null);
socket.connect((new InetSocketAddress(host, port)), 500);
/* Create a byte stream from a JPEG file and pipe it to the output stream  of the socket. This data will be retrieved by the server device. */
OutputStream outputStream = socket.getOutputStream();
ContentResolver cr = context.getContentResolver();
InputStream inputStream = null;
inputStream = cr.openInputStream(Uri.parse(“path/to/picture.jpg”));
while ((len = inputStream.read(buf)) != -1) {
outputStream.write(buf, 0, len);
}
outputStream.close();
inputStream.close();
} catch (FileNotFoundException e) {
//catch logic
} catch (IOException e) {
//catch logic
}
/* Clean up any open sockets when done transferring or if an exception occurred. */
finally {
if (socket != null) {
if (socket.isConnected()) {
try {
socket.close();
} catch (IOException e) {
//catch logic
}
}
}
}

Broadcast Receivers simply respond to broadcast messages from other applications or from the system itself. These messages are sometime called events or intents. For example, applications can also initiate broadcasts to let other applications know that some data has been downloaded to the device and is available for them to use, so this is broadcast receiver who will intercept this communication and will initiate appropriate action.

There are following two important steps to make BroadcastReceiver works for the system broadcasted intents −

• Creating the Broadcast Receiver.
• Registering Broadcast Receiver

There is one additional steps in case you are going to implement your custom intents then you will have to create and broadcast those intents.

Creating the Broadcast Receiver

A broadcast receiver is implemented as a subclass of BroadcastReceiverclass and overriding the onReceive() method where each message is received as a Intent object parameter.

public class MyReceiver extends BroadcastReceiver {
   @Override
   public void onReceive(Context context, Intent intent) {
      Toast.makeText(context, "Intent Detected.", Toast.LENGTH_LONG).show();
   }
}

Registering Broadcast Receiver

An application listens for specific broadcast intents by registering a broadcast receiver in AndroidManifest.xml file. Consider we are going to register MyReceiver for system generated event ACTION_BOOT_COMPLETED which is fired by the system once the Android system has completed the boot process.

BROADCAST-RECEIVER

<application
   android:icon="@drawable/ic_launcher"
   android:label="@string/app_name"
   android:theme="@style/AppTheme" >
   <receiver android:name="MyReceiver">
   
      <intent-filter>
         <action android:name="android.intent.action.BOOT_COMPLETED">
         </action>
      </intent-filter>
   
   </receiver>
</application>

Now whenever your Android device gets booted, it will be intercepted by BroadcastReceiver MyReceiver and implemented logic inside onReceive()will be executed.

There are several system generated events defined as final static fields in the Intent class. The following table lists a few important system events.

Broadcasting Custom Intents

If you want your application itself should generate and send custom intents then you will have to create and send those intents by using thesendBroadcast() method inside your activity class. If you use thesendStickyBroadcast(Intent) method, the Intent is sticky, meaning theIntent you are sending stays around after the broadcast is complete.

public void broadcastIntent(View view)
{
   Intent intent = new Intent();
   intent.setAction("com.tutorialspoint.CUSTOM_INTENT");
   sendBroadcast(intent);
}

This intent com.tutorialspoint.CUSTOM_INTENT can also be registered in similar way as we have regsitered system generated intent.

<application
   android:icon="@drawable/ic_launcher"
   android:label="@string/app_name"
   android:theme="@style/AppTheme" >
   <receiver android:name="MyReceiver">
   
      <intent-filter>
         <action android:name="com.tutorialspoint.CUSTOM_INTENT">
         </action>
      </intent-filter>
   
   </receiver>
</application>

Example

This example will explain you how to create BroadcastReceiver to intercept custom intent. Once you are familiar with custom intent, then you can program your application to intercept system generated intents. So let’s follow the following steps to modify the Android application we created inHello World Example chapter −

Following is the content of the modified main activity filesrc/com.example.My Application/MainActivity.java. This file can include each of the fundamental life cycle methods. We have addedbroadcastIntent() method to broadcast a custom intent.

package com.example.My Application;

import android.os.Bundle;
import android.app.Activity;
import android.view.Menu;
import android.content.Intent;
import android.view.View;

public class MainActivity extends Activity {

   @Override
   public void onCreate(Bundle savedInstanceState) {
      super.onCreate(savedInstanceState);
      setContentView(R.layout.activity_main);
      }
   
   @Override
   public boolean onCreateOptionsMenu(Menu menu) {
      getMenuInflater().inflate(R.menu.activity_main, menu);
      return true;
      }
   
   // broadcast a custom intent. 
   public void broadcastIntent(View view){
      Intent intent = new Intent();
      intent.setAction("com.tutorialspoint.CUSTOM_INTENT");
      sendBroadcast(intent);
   }
}

Following is the content of src/com.example.My Application/MyReceiver.java:

package com.example.My Application;

import android.content.BroadcastReceiver;
import android.content.Context;
import android.content.Intent;
import android.widget.Toast;

public class MyReceiver extends BroadcastReceiver {
   @Override
   public void onReceive(Context context, Intent intent) {
      Toast.makeText(context, "Intent Detected.", Toast.LENGTH_LONG).show();
   }
}

Following will the modified content of AndroidManifest.xml file. Here we have added <service…/> tag to include our service:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
   package="com.example.My Application"
   android:versionCode="1"
   android:versionName="1.0" >
   
   <uses-sdk
      android:minSdkVersion="8"
      android:targetSdkVersion="22" />
   
   <application
       android:icon="@drawable/ic_launcher"
       android:label="@string/app_name"
       android:theme="@style/AppTheme" >
       
       <activity
          android:name=".MainActivity"
          android:label="@string/title_activity_main" >
       
          <intent-filter>
             <action android:name="android.intent.action.MAIN" />
             <category android:name="android.intent.category.LAUNCHER"/>
          </intent-filter>
          
       </activity>
       
       <receiver android:name="MyReceiver">
       
       <intent-filter>
          <action android:name="com.tutorialspoint.CUSTOM_INTENT">
          </action>
       </intent-filter>
       
       </receiver>
       
   </application>
</manifest>

Following will be the content of res/layout/activity_main.xml file to include a button to broadcast our custom intent −

<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
   xmlns:tools="http://schemas.android.com/tools" android:layout_width="match_parent"
   android:layout_height="match_parent" android:paddingLeft="@dimen/activity_horizontal_margin"
   android:paddingRight="@dimen/activity_horizontal_margin"
   android:paddingTop="@dimen/activity_vertical_margin"
   android:paddingBottom="@dimen/activity_vertical_margin" tools:context=".MainActivity">
   
   <TextView
      android:id="@+id/textView1"
      android:layout_width="wrap_content"
      android:layout_height="wrap_content"
      android:text="Example of Broadcast"
      android:layout_alignParentTop="true"
      android:layout_centerHorizontal="true"
      android:textSize="30dp" />
      
   <TextView
      android:id="@+id/textView2"
      android:layout_width="wrap_content"
      android:layout_height="wrap_content"
      android:text="Tutorials point "
      android:textColor="#ff87ff09"
      android:textSize="30dp"
      android:layout_above="@+id/imageButton"
      android:layout_centerHorizontal="true"
      android:layout_marginBottom="40dp" />
      
   <ImageButton
      android:layout_width="wrap_content"
      android:layout_height="wrap_content"
      android:id="@+id/imageButton"
      android:src="@drawable/abc"
      android:layout_centerVertical="true"
      android:layout_centerHorizontal="true" />
      
   <Button
      android:layout_width="wrap_content"
      android:layout_height="wrap_content"
      android:id="@+id/button2"
      android:text="Broadcast Intent"
      android:onClick="broadcastIntent"
      android:layout_below="@+id/imageButton"
      android:layout_centerHorizontal="true" />

</RelativeLayout>

Following will be the content of res/values/strings.xml to define two new constants −

<resources>    
    <string name="menu_settings">Settings</string>
    <string name="title_activity_main">My Application</string>
</resources>

Let’s try to run our modified Hello World! application we just modified. I assume you had created your AVD while doing environment set-up. To run the app from Android studio, open one of your project’s activity files and click Run icon from the tool bar. Android Studio installs the app on your AVD and starts it and if everything is fine with your set-up and application, it will display following Emulator window −

Now to broadcast our custom intent, let’s click on Broadcast Intent button, this will broadcast our custom intent “com.tutorialspoint.CUSTOM_INTENT”which will be intercepted by our registered BroadcastReceiver i.e. MyReceiver and as per our implemented logic a toast will appear on the bottom of the the simulator as follows −

You can try implementing other BroadcastReceiver to intercept system generated intents like system boot up, date changed, low battery etc.

public class IndexProcessor implements Runnable {

    private static final Logger LOGGER = LoggerFactory.getLogger(IndexProcessor.class);
    private volatile boolean running = true;

    public void terminate() {
        running = false;
    }

    @Override
    public void run() {
        while (running) {
            try {
                LOGGER.debug("Sleeping...");
                Thread.sleep((long) 15000);

                LOGGER.debug("Processing");
            } catch (InterruptedException e) {
                LOGGER.error("Exception", e);
                running = false;
            }
        }

    }
}

The Java programming language provides two basic synchronization idioms: synchronized methods and synchronized statements. The more complex of the two, synchronized statements, are described in the next section. This section is about synchronized methods.

To make a method synchronized, simply add the synchronized keyword to its declaration:

public class SynchronizedCounter {
    private int c = 0;

    public synchronized void increment() {
        c++;
    }

    public synchronized void decrement() {
        c--;
    }

    public synchronized int value() {
        return c;
    }
}

If count is an instance of SynchronizedCounter, then making these methods synchronized has two effects:

• First, it is not possible for two invocations of synchronized methods on the same object to interleave. When one thread is executing a synchronized method for an object, all other threads that invoke synchronized methods for the same object block (suspend execution) until the first thread is done with the object.
• Second, when a synchronized method exits, it automatically establishes a happens-before relationship with any subsequent invocationof a synchronized method for the same object. This guarantees that changes to the state of the object are visible to all threads.

Note that constructors cannot be synchronized — using the synchronized keyword with a constructor is a syntax error. Synchronizing constructors doesn’t make sense, because only the thread that creates an object should have access to it while it is being constructed.

instances.add(this);

Synchronized methods enable a simple strategy for preventing thread interference and memory consistency errors: if an object is visible to more than one thread, all reads or writes to that object’s variables are done through synchronized methods. (An important exception: finalfields, which cannot be modified after the object is constructed, can be safely read through non-synchronized methods, once the object is constructed) This strategy is effective, but can present problems with liveness, as we’ll see later in this lesson.

In this example we are going to talk about a very common exception that many java developers stumble upon when dealing with IO operations in their program : IOException. This exception occurs when an IO operation has failed for some reason. It is also a checked exception which means that your program has to handle it. All bult-in Java IO methods that might cause an IOException, explicitly throw it so that your program can handle it. It is also worth noting that the IOException object that your program receives is accompanied by a String message that can inform you as accurately as possible for the cause of the exception.

Also, IOException is the most general class that can describe anIOException. Several subclass of it exist in order to reveal the problem that occurred in a more specific and detailed manner. Some of the most well know sub classes are FileNotFoundException,EOFException, UnsupportedEncodingException, SocketException, SSLException

1. A simple case of IOException

Let’s see a very simple case of an IOException. In the following example we are going to try to read some lines of text form a file that does not exist:

IOExceptionExample.java:

package com.javacodegeeks.core.io.ioexception;

import java.io.BufferedReader;
import java.io.FileReader;
import java.io.IOException;

public class IOExceptionExample {

	private static String filepath = "C:\\Users\\nikos\\Desktop\\TestFiles\\testFile2.txt";
	
	public static void main(String[] args) {
		
		BufferedReader br = null;
		String curline;
		try {
			br = new BufferedReader(new FileReader(filepath));

			while ((curline = br.readLine()) != null) {
				System.out.println(curline);
			}

		} catch (IOException e) {
		
			System.err.println("An IOException was caught :"+e.getMessage());
		
		}finally{
			
			try {
				
				if(br != null)
					br.close();
			
			} catch (IOException e) {
				
				e.printStackTrace();
			}
		}

	}

}

Now, when I run this program, because the file C:\\Users\\nikos\\Desktop\\TestFiles\\testFile2.txt does not exist, it will output:

An IOException was caught :C:\Users\nikos\Desktop\TestFiles\testFile2.txt (The system cannot find the file specified)

2. How to solve IOException

As you’ve seen IOException is a very general exception that occurs when an IO operations fails. So you can understand that there is no standard way on how to solve this exception. The best thing you can do is to explicitly handle the exception in a try-catch block and print out the message of the exception. Then you can take the correct actions to solve this situation. For example, in the previous code snippet, the message clearly states that the file does not exist. So you should go ahead and create the file. It can also say :”Permission Denied”. This means that you should check if you have the permission to perform the action you requested in that file. If you are working with streams and especially with sockets and the stream is closed in the middle of your session you could see a message like :”Stream Closed” that designates the problem exactly .

Download Source Code

This was an example on java.io.IOException. Download the source code of this example here : IOExceptionExample.zip