Developing an app can be a long, tough and never-ending battle. From writing the specifications, developing the app and testing it, the technical team has to go by a long process. Here at Matchmore, we know it can be both time and energy consuming. Therefore, we have created a phone motion simulator which will heavily reduce the testing time and facilitate the testing procedures of the creation of proximity-based apps.

Compared to traditional applications, mobile context-aware applications offer new usages to users and developers. Adding the concept of context-awareness to an app make it more efficient, but it's also tricky to implement. Nonetheless, many uses cases of mobile context-aware applications prove that it's worth it. For instance, mobile context-aware e-commerce applications have been identified by the Information Systems Community as the natural evolution in the field of mobile application.[1]

One of the key challenges at Matchmore is to provide developers with ready-to-use tools to help them build their context-awareness app easily. Our most recent tool that we provide is Phomo, a homemade phone simulator that will allow you to use Matchmore with a few, or no, lines of code. Imagine to be able to test your newly created proximity-based app from your computer, instead of leaving the office and asking a friend or two to bring their smart phones outside.

What is Phomo?

Phomo is a phone motion simulator that allows developers to deal with the problems induced by the testing of location based applications. Accessible on a web platform, it helps developers to simulate motion of devices based on a defined mobility model. It also allows to easily create publications and subscriptions without using a physical device and without writing a single line of code. Developers can use Phomo as a testing tool to setup their apps, and prospective users can see it as an entry-point in the Matchmore environment.

Getting started: How to use Phomo

In this part, we will do some simple manipulations in order to receive a match between two devices, one publisher and one subscriber. In the following parts, we will go more into details.

To start using the web version of Phomo that we provide on our website, you have to create an account on this link, and then create an app. It's free to register!
create-app-1
Once it's done, you have to go under the Tools menu, then click on Phomo. On the Phomo page, you have to follow the steps below:

  • Select an app.
  • Create a new scenario.
  • Add a name.
  • Select a scenario.
  • In the Device's tab, you have to click on Add a device.
  • On the map, you have to place a point which represents the place where you want to create a publication/subscription. By default, tag the device as a pinpoint without any mobility model. Then click on Add to see the device on the map.
  • Create another device close to the first one.
  • Now, click on the Publication's tab.
  • Add a publication by clicking on the appropriate button and associate it with the first device.
  • Fill in range, duration and properties.
  • Create a subscription by following the same steps as described above but by clicking on Subscription tab.

If the publication and the subscription have the same topic and overlaps, there will be a match! That's how Matchmore works!

Now, let's dig a little deeper.

Scenario

By using Phomo, you can split your work into multiple scenarios. Each scenario
can have several devices, different mobility models and many operational pubs and subs. You can save your scenarios in your Phomo panel or export it by clicking on the Download button (under the Devices tab). It will automatically download a json file (devices.json) containing the details of your scenario.

{
  "scenario": [
    {
      "device": {
        "name": "d1",
        "location": {
          "latitude": 46.21389047754758,
          "longitude": 6.122688054019818,
          "altitude": 0
        },
        "deviceType": "PinDevice",
        "id": "ca482c46-dc47-46bd-8044-a9c76b70c6c9",
        "createdAt": 1546867325997,
        "mobilityModel": {
          "internalId": "b81d6e64-19a5-2c4f-a837-94acd6ab6704",
          "type": "static",
          "name": "Not move",
          "location": {
            "latitude": 46.21389047754758,
            "longitude": 6.122688054019818,
            "altitude": 0
          }
        }
      },
      "pubs": [],
      "subs": []
    },
    {
      "device": {
        "name": "d2",
        "location": {
          "latitude": 46.213593516220854,
          "longitude": 6.1409270753210885,
          "altitude": 0
        },
        "deviceType": "PinDevice",
        "id": "705309ff-5a94-4dc9-b96d-ce53053a47e9",
        "createdAt": 1546867332985,
        "mobilityModel": {
          "internalId": "45a13c25-7304-26b9-101f-2db7dc1292d1",
          "type": "static",
          "name": "Not move",
          "location": {
            "latitude": 46.213593516220854,
            "longitude": 6.1409270753210885,
            "altitude": 0
          }
        }
      },
      "pubs": [],
      "subs": []
    }
  ],
  "models": []
}

Example of a file containing all the details of a scenario.

It's therefore possible to load your saved scenarios by uploading a scenario's file under the Devices loading button.

Devices

On Phomo, a device is identified by its name, its type and its mobility model. Its name must be any set of numeric/alphanumeric character. The device's type must be a mobile device, a pinpoint or a beacon. (The mobility model will be discussed further down.)

Mobile device

A mobile device acts like a physical device. It is defined by its device token (an Universally Unique IDentifier (UUID)), its platform and its location. An example of mobile device created on Phomo may look like this:

{
	"deviceType": "Mobile",
	"Platform": "Android",
	"token":"8eca31e4-77bf-404c-8f9a-499a8bdd5b1d",
    "latitude": 46.519962
    "longitude": 6.633597
}

On the Matchmore's platform, in general, mobile devices are physical devices (smart phones, tablets, computers, PDAs...)

Pinpoint

On the web version of Phomo, just like the mobile device, a pinpoint is a virtual point with GPS coordinates. It has a name and can be assigned a mobility model. A practical use case for pinpoint can be a geo-targeting advertising campaign around a shop. The pinpoint is designed to be easily deployed. A pinpoint will look like this once it is set up on Phomo:

{
	"deviceType": "Pin",
    "latitude": 46.519962
    "longitude": 6.633597
}

Beacon

Beacons are wireless devices that help indoor and outdoor positioning. Beacons use the Bluetooth Low Energy (BLE) technology to transmit data over short distances. The design of BLE is intended to provide low energy consumption, thus allowing the beacon’s battery to last longer than the original Bluetooth technology. The battery duration of BLE goes between 2 to 3 years [2].

On Phomo, we identify a beacon based on 3 values:

  • The major is a 2 bytes number from 1 to 65,535.
  • The minor same as major.
  • An UUID is a 16 bytes, usually represented as a string.

One could use the UUID to distinguish beacons in one’s network, from all other beacons in networks outside of his control. Major and minor could be considered as a supplement layer to identify beacons with greater accuracy than using the UUID alone.

For more details, do not hesitate to read the following blog posts about beacons:

Everything you need to know about beacons
How to use beacons with Matchmore
How to secure your beacons from being spoofed
How to build an event app with Matchmore and beacons

Mobility model

A mobility model represents the way one or several mobile nodes move, change direction, change their speed or pause over time.

The research community has defined many mobility models and the most common ones are already available in Phomo. The majority of these models, such as Random Waypoint, Random Walk or Path models are automated and do not need user interaction to function. However, the Interactive Mobility Model allows the user to interactively control the device.

We can define 6 personalized routes:

  • Random walk distance: In this mode, the device moves at a constant speed until it reaches set distance. After that, it selects new direction.
  • Random walk time: Same as the previous one except with one slightly difference. Here, the device moves with constant speed for given period. After that, it selects new direction.
  • Random way point: The device moves in the direction of a randomly selected point within specified range. After reaching that point, it selects the new destination.
  • GPS model: This mode allows you to import your GPS waypoint, tracks and routes. It is an open format which can be used without the need to pay license fees. It is compatible with many GPS mapping software.
  • Interactive mode: Allows you to create a personalized path by placing the starting point and by drawing the path using your keyboard (a for left, s for down, d for right and w for up).
  • Path: Instead of drawing a path manually, we allow you to indicate the path of your device by placing points on the map. The device will move according to the path defined by selected points. After reaching the end of the path, it will follow the same path backward. This option is useful when you want to define a path on a large distance.

Each mobility model is identified by its name and type, it can be deleted by clicking on the trash button under the Mobility tab.

Publications & Subscriptions

In software architecture, publish–subscribe is a messaging pattern where senders of messages, called publishers, do not program the messages to be sent directly to specific receivers, called subscribers, but instead categorize published messages into classes without knowledge of which subscribers, if any, there may be. Similarly, subscribers express interest in one or more classes and only receive messages that are of interest, without knowledge of which publishers, if any, there are. [3]

Using the publish-subscribe pattern, the users do not necessarily know who they are communicating with, data is published to the system as a whole and subscribers receive data from the system.

1211_Figure-1-Publish-Subscribe-Diagram_c
An example of a publish-subscribe system (Source: Nuvation Engineering ).

Publications

One of the main purposes of Phomo is to facilitate the creation of publications and subscriptions without typing any line of code.

To create a publication, you must click of the Pub tab, then Add a publication. A publication requires at least 4 parameters (device, topic, range, duration) and some properties.

On the publication tab, you can see the list of all your devices on a drop-down list. The topic's field is one of the most important point, it's the main element to trigger a match between a publication and a subscription. After setting up a topic, you can set up the range of your publication (in meter), the duration (in seconds) and the properties.

The properties take an input a dictionary of key, value pairs. As values, it allows numbers, booleans, string and array of aforementioned types.

{
"id": "string",
"createdAt": 0,
"worldId": "string",
"deviceId": "string",
"topic": "string",
"range": 0,
"duration": 0,
"properties": {
"band": "Metallica",
"tags": [],
"price": 400,
"currency": "CHF",
"free_parking": true
}
}

Example of a publication.

Subscriptions

Same as publications, subscriptions take as input a device, a topic, a range, a duration and some additional, yet optional, parameters like the Match TTL, MatchDTL and some selectors.

The MatchTTL (in seconds), also known as Match Time-To-Leave, tells when to deliver consecutive matches with the same publication. For example, if a publication and a subscription are still in the range of each other after the matchTTL expires, next match will be sent to subscription. This parameter is useful when you have long-lasting publications/subscriptions, and you want to be notified when a match occurs after some time.

The MatchDTL (in meters), also known as Match Distance-to-Leave, says if the subscription will get a match again when the position of publication or subscription changes by the defined matchDTL (publication and subscription still have to be in range after the change). This parameter is useful if you have large subscription/publication and subscription should get a match every time publication or subscription moves by matchDTL meters.

The selector is an expression to filter the publications. For instance, "job=developer" will allow matching only with publications containing a 'job' key with a value of 'developer'.

When a publication and subscription share the same topic and overlap on the same range (with the same parameters in such a way that the properties tie in with the selector), a match is automatically triggered.

The data is “persistent”, meaning that the last published data for a particular topic will be available to subscribers that register on the system after the publisher last published the data.

Practical use case

As a use case, consider creating smart notifications every time an app user comes close to a set of shops. Let's assume there is a shop, café or restaurant which would like to send out promotions to their customers when they are nearby. This could be applied to any business, as long as they provide an app to their customers/users.

In this example, we will use the example of one tourist visiting and one city resident. They both possess the app of the local shop.

For our scenario, we have to create at least 2 types of devices:

  • Pinpoint: Since it has precise geographic coordinates that doesn't need to be adjusted, a pinpoint is the perfect type of device for this scenario. To be clear, this pinpoint represents the shop.
  • Mobile devices: Associated with a mobility pattern, each mobile device will represent an app user. Some of the users will use a random mobility model while some others will use a precise path. These mobile devices will represent the tourist and the city resident.

A publication will be created on the pinpoint with the same topic, the only difference will be the location and the properties associated to each pinpoint. The properties will give more details about the shop, like the products available, the shop's address and the discount on some products.

After assigning a mobility model to the mobile devices, we will then create a subscription on each mobile device. The suscriptions should have the same topics as the publications. We can even create a filter based on the user's preferences.

Let's start!

First of all, after logging into the Matchmore's website, go to Phomo and create a new scenario. Let's call it Shop.

Then let's create the devices, we will start by adding some shops. As we mentioned above, the shops will be set up as Pin devices, let's call them Shop1, Shop2 and Shop3.

Before creating the users' devices, we have to set up the mobility models which will be assign to every mobile device. To make it simple, we will only have two users: One tourist and a city resident.

The tourist will walk randomly around the city, and the city resident will have a predefined path. According to some studies, the average walking speed for a young pedestrian is between 5.32 and 5.43 kilometers per hour (1.477778 - 1.508333 meter per second) [4] [5]. In our mobility model, we will set the speed at 1.5 meter per second.

The tourist will change his direction after 10 meters, meanwhile, we will define the path of the resident. He will have to pass near all the shops.

Now, let's create the user's devices and assign them with a proximity model.
We will call our mobile devices: Tourist and city resident.

Publications

Once it's done, we can create our publications and assign them to the shops.The topic can be any catchy word, let's use nearby_shops. The range should be either close to the shops or around the street where the shop is located. We will set a range of 50 meters (near) and 250 meters (wide), a duration of 1 week (604,800 seconds) and some properties (shop's name, address, products available and a custom message).

In order to link the customers to the shops, they need to subscribe to the publications made by the shops. If the criteria are the same, there will be a match.

Subscriptions

We have to create the subscriptions with the same topic than the publications: nearby_shops, one subscription per user. For the city resident, we will add a selector on his subscription to filter only the publication that matches his needs. For example, the resident should look only for Yoghurts.

To create a subscription, we will follow close to the same steps than the ones we followed for the publications. The range will be set at 10 meters around the user, the duration will be one hour (3,600 seconds) and for the resident, we will fill the selector's field by adding: "products_available"="Yoghurts"

Screenshot-2019-01-09-at-14.21.20

Your dashboard should look like this. The blue circles around the pinpoints represent the ranges of the publications, and two orange circles represent the subscriptions around the mobile devices. Practically speaking, the pinpoints with the larger circles represent the shops. The green and purple pinpoints up to the right represent the users, the tourist and the city resident, with small ranges. Every time the users pass within the shops' ranges, they will receive a personalized message from the shop.

You can click on the Start Button next to the scenario drop-down button to see Phomo in action.

Conclusion

With Phomo, users now have a tool to test their apps and will have an overview of Matchmore's work without typing any line of code. It is means to be simple while helping the users on their most common task. Many new features are expected to be built around Phomo to increase it's central role in the Matchmore toolbox.

I hope you liked this blog post, if you have any question about Phomo, please feel free to drop me an email on alpha.diallo@matchmore.com.


  1. Mathew, J., Sarker, S., & Varshney, U. (2004). M-commerce services: Promises and challenges. Communications of the AIS ↩︎

  2. http://www.ibeacon.com/what-is-ibeacon-a-guide-to-beacons/ ↩︎

  3. https://en.wikipedia.org/wiki/Publish–subscribe_pattern ↩︎

  4. "Study Compares Older and Younger Pedestrian Walking Speeds". TranSafety, Inc. 1997-10-01. Retrieved 2009-08-24. ↩︎

  5. Aspelin, Karen (2005-05-25). "Establishing Pedestrian Walking Speeds" (PDF). Portland State University. Retrieved 2009-08-24. ↩︎