Error type 3: Activity class does not exist

This happens when you do the following

• connect your device/emulator
• run the app from Android Studio (AS)
• use/test the app and uninstall it from the device while it is still connected to your computer
• try to run the app again from AS

AS thinks you still have the app in your device.

tl;dr - To resolve this issue for connected devices you can uninstall with ADB:

$ adb shell pm list packages

package:com.foo.foo

$ adb uninstall com.foo.foo

Success

Run app from AS again after uninstalling with ADB.

Part 2: React in Electron

The ability to utilize next-gen building platforms without headache-free style

---

What headache? Are you a f**##$ idiot?!

There's no bigger headache for me than to exercise hours for build tools, and non-trivial development pipelines at the inception of a project.

React is a library who's intention is to simplify the development of user facing applications; and built by Facebook (Thanks Facebook!).

(Oh yeah, it uses Javascript.. That is pretty cool.)

---

RE: React, play well with Electron

    <script type="text/javascript" src="https://cdnjs.cloudflare.com/ajax/libs/react/15.0.1/react.js"></script>
    <script type="text/javascript" src="https://cdnjs.cloudflare.com/ajax/libs/react/15.0.1/react-dom.js"></script>
    <script type="text/javascript" src="https://cdnjs.cloudflare.com/ajax/libs/axios/0.8.1/axios.min.js"></script>
    <script type="text/javascript" src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.0.0-alpha1/jquery.min.js"></script>
    <script type="text/javascript" src="https://cdnjs.cloudflare.com/ajax/libs/babel-core/5.8.23/browser.min.js"></script>

dependencies necessary for React to play with Electron, plus axios

Let's get some React to integrate!

Check out this awesome project at CodePen!

ok, plugging it in, you should have something similar to the project in this repo!

Part 1: Child process as prelude to interprocess communication

The child process as prelude to interprocess communication

---

What the hell are you talking about??
Not EMScripten, not any R&D cool finding, just some observation of using the Electron app pattern.

Electron is a cross-platform framework that glues system and browser via interprocess communications; and developed by Github (major thanks!).

(Oh yeah, it uses Javascript.. That is pretty cool.)

---

EE: Electron boiler, meet Express boiler

'use strict';

const electron = require('electron');
const app = electron.app;
const BrowserWindow = electron.BrowserWindow;
const url = 'http://127.0.0.1:1987';

let mainWindow, child;

function windowRouter(_route) {
  return url + '/' + (_route || '');
}

function renderWindow() {
  mainWindow = new BrowserWindow({width: 800, height: 600});
  mainWindow.loadURL(windowRouter());
  // default to inspector mode in Chromium
  mainWindow.webContents.openDevTools();
  mainWindow.on('closed', function() {
    mainWindow = null;
  });
}

function createWindow () {
  renderWindow();
  let exec = require('child_process').exec;
  child = exec('node ./server.js');
  child.stdout.on('data', function(data) {
      console.log('stdout: ' + data);
  });
  child.stderr.on('data', function(data) {
      console.log('stdout: ' + data);
  });
  child.on('close', function(code) {
      console.log('closing code: ' + code);
      child.kill();
  });
}

app.on('ready', createWindow);

app.on('window-all-closed', function () {
  if (process.platform !== 'darwin') {
    app.quit();
    child.kill();
  }
});

app.on('activate', function () {
  if (mainWindow === null) {
    createWindow();
  }
});

main.js

#!/usr/bin/env node
var express = require('express');
var app = module.exports = express();
var server = require('http').createServer(app);
var bodyParser = require('body-parser');
app.set('trust proxy', true);
app.use(bodyParser.json({limit: '50mb'}));
app.use(bodyParser.urlencoded({limit: '50mb', extended: true}));
app.use(require('cookie-parser')());

app.get('/', function(req, res) {
  console.log('GET /');
  res.send('<h1>foo lala</h1>');
})

var port = 1987;
var ipaddr = '127.0.0.1';
server.listen(port, ipaddr, function() {
  console.log('Express server listening on port ' + server.address().port + ' at ' + server.address().address);
});

server.js

npm start

> electron-quick-start@1.0.0 start /var/www/electron-quick-start
> electron main.js

stdout: Express server listening on port 1987 at 127.0.0.1

stdout: GET /

terminal

browser

The JS above was near identical, and the HTML was identical, to Electron's boilerplate, and package.json required modifying the additional packages. It's a good place to start!

JS E Patterns

Events in JS are pretty amazing, and notifications or emits or emissions or what have you are quite often fundamental to programming with JS. In the case of UI it's literally every user interaction; and for pubsub mechanisms the same also holds true.

JS has a method Event.stopPropagation that here I will make the case introduces an anti-pattern to your code.

Here's the scenario:

user clicks submit on a form button, the code would look like the following:

submit.onclick = function(e) {
e.preventDefault() // similar method here
// .. do your thing
e.stopPropagation(); // stop furthering the event
}

1) Event occurs, and there is one file, and one method that the event is used.

Stopping event propagation here is nominal. This is a good use case, although it wouldn't make much difference to use stopPropagation.

2) You have multiple files that have multiple event listener methods.

Using stopEventPropagation should be avoided because it can act as an anti-pattern, here's how:

Let's say we have two different methods, and in two different files:

method1, file1

function eListener1(e, p) {
// tasks of eL1
}

and

method2, file2

function eListener2(e, p) {
// tasks of eL2
}

By definition, the layout of your code is completely different in the two scenarios .. one you're very much in the same place, and the other you leave to the great open yonder, not knowing exactly why or who is going to use something from somewhere as you're buidling.

To stop event propagation here is a mistake, and it would block tasks including delegation, and future use cases. For instance, suppose that your event is currently active in eL1 above; and now you want to create another event listener in another class or file that you will call eListener3 to perform some task on the same event. You would not be able to do this with stopPropagation; in effect you've limited your own possibilities, and another rate limiting step added to the soup is now that method that I will argue should have been avoided.

Stopping propagation is appropriate for a terminal event, such as deleting an item that has a known end; and not for general user interaction events. Signing out, for instance, could be another use case, however, would be redundant in many cases.

For general events, it's wasted energy. The consideration for stopEventPropagation at the general event level is perhaps at the heart of the rift between TCP or UDP versus TCP/IP.

In general, it's a good idea to avoid exotic methods unless you know exactly why you're using them. However, if you are building massively scaled TCP/IP request based systems that send large amounts of data, then this may not apply to you. 

A potential or real benefit of stopEventPropagation is saving computing and/or bandwidth resources.

So what's someone to do without stopping propagation?? Glad you asked, it's the simple conditional. The key here is to add a unique identifier to your object (i.e. this.supercalifradgilisticexpialidocious = 'here it is';), and in every one of your listeners you'd have your conditionals:

function eListener3(e, p) {
if (e === 'click') {
switch (p.foo.supercalifradgilisticexpialidocious) {
case 'here it is': {
// do func
break;
}

default: break;
}
}
}

Local Sublime Text via remote SSH

Initially, for myself, and quite ashamedly as with many other facets .. I created an alias to access my SSH .. as a way to avoid lookup of the IP address you know? I cringe now, believe you me.

Well, then I needed to have access to Sublime Text in my remote environment as a way to make life a wee more convenient (i.e. in this case WAY more convenient), and figured to let you know how I did in case it may help.

---

There are good articles about how to configure your local and SSH environments with Sublime Text, such as this one written by Limina Studio and this one written by Daniel Demmel.

One other key piece of information is the function of the ~/.ssh/config file itself. There's a great writeup available from Nerderati available from this link.

The workflow is as follows:

1. Install the rsub plugin from the Package Control of Sublime or instructions provided from the public Github repository,

2. In your local environment edit your ~/.ssh/config file and specify your SSH IP address and User:

Host yourAlias
    HostName "$IP"
    User "$USER"
    RemoteForward 52698 127.0.0.1:52698

3. In your SSH environment, as root, do:

# wget -O /usr/local/bin/rsub https://raw.github.com/aurora/rmate/master/rmate
# chmod +x /usr/local/bin/rsub
# shutdown -r now

4. Henceforth, you may now access your SSH similar to what would be an alias:

$ ssh yourAlias

5. Restart Sublime, SSH in, and there will be an added advantage of being able to edit files via your local environment's Sublime Text editor.

Guidelines for clinicians

Pleased to announce Guidelines a resource for clinicians.

This was a project long overdue.

1) Single site access to gold standard guidelines is surprisingly still not addressed

The purpose of Guidelines is very pure and simple: frequently or semi-frequently the world leading associations issue recommended guidelines that clinicians utilize on a daily basis to treat medically compromised patients.

The variety and scope of these publications may be wide, however, there are a number of well defined sources that are pre-selected as the authority or gold standard of care. Therefore, curation of these Guidelines is not as labor intensive or time consuming to warrant an establishment for their organization; and thus, remain neglected.

2) Clinicians should conveniently be able to access Guidelines

Of anyone with their plate already full, the clinician will foreseeably be too consumed in other activities to maintain a dedicated, and convenient, point of entry towards their access to the most current, and relevant, standards.

The clinician may not even have convenient access to a list of gold standard resources they once may have had. Once a clinician enters private practice, they risk becoming isolated and sandboxed out of such resources that may often go unnoticed or unappreciated.

As a result, the clinician may compromise their ability to receive a thorough, and up to date, criteria or list of standards they may study. Subsequently, patients are the population who bear the results of this risk.

3) When clinicians have access to resources, patients benefit

The sole purpose of a clinical practice, and hence Guidelines, is to benefit the patient.

There should not be an issue that exists today caused by a barrier of access to information that is readily available over the wire. Therefore, instruments such as Guidelines exist to facilitate the transfer of information to maintain a peer reviewed, updated, thorough, and accessible list of resources available to clinicians via a multitude of avenues.

OPEN CALL FOR CLINICAL SCIENCE CONTRIBUTORS

ALL DISCIPLINES OF HEALTH CARE

PROJECT AVAILABLE ON GITHUB FOR IMMEDIATE CONTRIBUTION

---

Step by step breakdown of IBM Bluemix image deploy

Step by step breakdown of IBM Bluemix

1) Creating local image

$ ice --local build -t $IMAGE_NAME:$TAG $DIR

The first step of working with Bluemix is to create a local image. This step is analogous to creating an image in Docker. The main difference is that the build produced here can be pushed to the IBM Bluemix cloud repository. Bluemix can connect to Dockerhub, however, it can also host your images privately out of the box, and sync with your local Docker daemon images.

SUPPORT

2) Tag and Push

$ ice --local tag $IMAGE_NAME $REGISTRY_URL/$NAMESPACE/$IMAGE_NAME:$TAG

$ ice --local push$REGISTRY_URL/$NAMESPACE/$IMAGE_NAME:$TAG

The local image is now tagged, and pushed to the IBM Bluemix cloud repository for use to add to a container in the following step.

SUPPORT

3) Create and run container

$ ice run --name $UNIQUE_CONTAINER_NAME $EXPOSED_PORTS $NAMESPACE/$IMAGE_NAME:$TAG

This piece may throw some people off base, and for good reason: "How come is it when I delete a container that I can no longer use that container's name?". Indeed, each time you apply an image to a cloud container, the cloud container needs a unique name that was never used before. Otherwise, you'll soon find that there will be an exception that the container already exists. It's a cloud repository after all. Therefore, assign a new name for a container each time you decide to run this command.

After this step you're done! You can of course, continue either by having access to a public IP address or by making code edits, and having to handle changes thereof.

SUPPORT

4) Access your public IP address if you don't have one already

$ ice ip request

The next step is self-explanatory. I hope you can foresee that you'll then have to assign this IP address to your cloud container for it to do anything useful. You may also derive a public IP address by utilizing the IBM Bluemix GUI instead of the CLI.

5) Bind/unbind IP address to a cloud container

$ ice ip unbind $PUBLIC_IP_ADDR $OLD_CONTAINER_NAME

$ ice ip bind $PUBLIC_IP_ADDR $UNIQUE_CONTAINER_NAME

In case you'd like to bind a public IP address, for instance to access various ports inside your application, you will have to bind them. I have been avoiding to run this step if another container is using the public IP address my clients utilize. This is preceded by unbind or stopping and removing the other container running the application. Of course, be careful when removing your container as it can no longer start. You may keep previous container(s) to revert in case your new adjustments have corrupted your code.

6) Logging

$ ice logs $UNIQUE_CONTAINER_NAME

The ability to log was a paramount concern. In addition to options such as SSH to your container, you can login to your IBM Bluemix from a Docker VM environment, and view your logs in real time.

7) Cleanup

$ ice rm $OLD_CONTAINER_NAME

Let's get rid of the previous, inactive, and unbound container for good measure and housekeeping.

To remove previous images, simply get rid of them from local and cloud

$ ice --local rmi $REGISTRY_URL/$NAMESPACE/$IMAGE_NAME:$TAG

$ ice --local rmi $NAMESPACE/$IMAGE_NAME:$TAG

$ ice --cloud rmi $NAMESPACE/$IMAGE_NAME:$TAG

Check out the BlueImage script for automation of simple deployments outlined above