Java – Use the Android foreground service to create notifications for MediaPlayer

Here’s the problem

I’m currently working on a must-offer app :

Radio player (AAC live stream from URL)
and a PodCast player (streaming MP3 from URL).

The application must be able to run in the background (Android service) and be exposed to the user through persistent notifications in the notification bar (Android foreground service).

(One question per question, so here I will ask for notice)

Because I have several classes for managing players, it’s a good idea for me to create a generic class for notifications though. This is the View I want to create:

.

This is my notification class now:

public class StreamingNotification extends NotificationCompat {
    /**
     * PRIVATE ATTRIBUTES
     */
    .log
    private static final String         TAG             = StreamingNotification.class.getSimpleName();
     notification
    private NotificationManager         _notificationManager;
    private NotificationCompat.Builder  _builder        = null;
    private Notification                _notification;
     data
    public static final int             NOTIFICATION_ID = 1;
    private Class                       _notifActivity;
    private Context                     _context;
    private String                      _notifTitle;
    private String                      _notifText;
    private int                         _notifLayout;

public StreamingNotification(String _notifActivity, Context _context, String _notifTitle, String _notifText, int _notifLayout) {

super();
        try {
            this._notifActivity = Class.forName(_notifActivity);
        }
        catch (ClassNotFoundException e) {
            e.printStackTrace();
        }
        this._context = _context;
        this._notifTitle = _notifTitle;
        this._notifText = _notifText;
        this._notifLayout = _notifLayout;
         manager
        _notificationManager = (NotificationManager)_context.getSystemService(Context.NOTIFICATION_SERVICE);
         notif builder
        _builder = new NotificationCompat.Builder(_context);
        buildSimpleNotification();
    }

private void buildSimpleNotification() {

 notif intent
        final Intent notificationIntent = new Intent(_context, _notifActivity);
        notificationIntent.setFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP | Intent.FLAG_ACTIVITY_SINGLE_TOP);
         remote view
        RemoteViews contentView = new RemoteViews(_context.getPackageName(), _notifLayout);
         pending intent
        final PendingIntent contentIntent = PendingIntent.getActivity(_context, NOTIFICATION_ID, notificationIntent, PendingIntent.FLAG_UPDATE_CURRENT);
        _builder.setContentIntent(contentIntent).setContent(contentView).setOngoing(true).setWhen(System.currentTimeMillis()).setAutoCancel(false).setContentTitle(_notifTitle )
            .setContentText(_notifText);
         notification build
        _notification = _builder.getNotification();
        _notification.flags |= Notification.FLAG_ONGOING_EVENT | Notification.FLAG_FOREGROUND_SERVICE | Notification.FLAG_NO_CLEAR;
        _notificationManager.notify(NOTIFICATION_ID, _notification);
    }
    [GETTERS AND SETTERS]
}

Am I doing it right? How will you manage RemoteViews custom notifications?

In this case, finding an authoritative source is a bit difficult because most music players are closed-source, and hardly anyone else uses this extended View control notification.

From a stylistic point of view, I delegate to NotificationCompat instead of extending it. This way, you can provide a simpler API internally instead of exposing the entire NotificationCompat.

As for RemoteViews, I’m not sure exactly what you’re asking. Whatever you do, as long as you keep the Notification instance, you can persist the instance to the RemoteViews (or individual views) and update them as needed. If you use delegate instead of inheritance, it is clearer because it makes sense in a way like “this field is a notification and this field is its View”.

P.S. From a purely syntactic point of view, try to use the framework naming guidelines. Most notably, fields are prefixed with “m” and use a camel (for example, mNotifTitle). Finally, private fields are well-tested kryptonite.