Multipeer Connectivity

The Multipeer Connectivity APIs, introduced by Apple in iOS 7 is an easy way to start building apps requiring peer-to-peer communication. Nearby devices communicate over infrastructure Wi-Fi networks, peer-to-peer Wi-Fi, and Bluetooth personal area networks. Connected peers are able securely transmit messages, streams, or file resources to other devices.

Evaluation of different aspects of Multipeer Connectivity with iPad Air 2 devices shows surprising results. Discovery and communication between iPad devices works mostly well. However, some shortcomings are to be mentioned here.

  • Establishing connection between peers always requires user interaction. The user has to confirm a connection to other device. There is no way to work with certificates or white lists of devices.
  • The other issue is that the framework does not always repair the broken ad-hoc network correctly. If a peer suddenly leaves the network, it often stays broken. Discovery must be restarted manually.
  • Multipeer Connectivity framework is only available for iOS, macOS and tvOS devices. So if the app has to run also on Android or Windows devices, this framework cannot be used.

To read more about Multipeer Connectivity refer to nshipster and apple’s doc.

PolterApp Version 1.8

PolterAppDas achte Update der beliebten Holzaufnahme-App bringt einige Verbesserungen in der Oberfläche und Nutzerführung. Bessere Aufteilung der funktionalen Elemente und unterstützende Animationen machen die Eingabe der Daten einfacher und die Arbeit mit der App angenehmer. Die neue Version der PolterApp is ab sofort zum Download im App-Store verfügbar.

Routing in ad-hoc Networks

devices-341443_640What does make routing and communication in Ad Hoc Networks different from routing and communication in usual LANs, WANs etc.? The main peculiarities are the absence of wires, routers and any predefined infrastructure. The nodes communicate with each other over the air and this is a very unreliable medium. Because of reflection, diffraction, diffusion and other signal propogation properties the data exchanging by nodes is frequently lost. Not only the connections between nodes can break, but the nodes move and the topology of the network can change any time.

Taking into consideration all these facts, it’s obvious that the standard approaches applicable to the usual networks with pre-existing infrastructure aren’t suitable in general for the ad hoc networks. In following I’d like to tell a couple of words to ISO/OSI layers and explain briefly how they are realized in ad hoc networks.

Data Link Layer.
In Ethernet the Carrier Sense Multiple Access Collision Detection (CSMA/CD) is mostly used as the Medium Access Control Protocol. This protocol does not work well in ad hoc network. So imagine there is a node A that wants to send a packet to the other node B. A has to be sure that no other neighbour is sending at the moment to avoid collisions. If medium is already in use, A has to wait. The main lack of this approach is so called Hidden Terminal Problem. hiddenterminalThe picture depicts it. The node C is hidden from the node A. If C is already sending and A wants to send, it can’t find any sending nodes nearby, so it starts sending too. It leads to a collisions at the node B.
That’s why IEEE 802.11 offers the alternative MAC protocol that partly solves this problem. If the node A wants to send some packet to the node B and the medium is free, A sends first of all a short RTS (ready to send) signal. All the neighbours of A know then that A is going to send. When B recieves RTS it sends CTS (clear to send) signal, and thus all the neihbours of B know that B is going to recieve. After the transmition B sends an ACK and it releases the medium for the neighbours.

Network Layer.
The most important and interesting question is how one node finds a multi-hop path to the other node. Routing protocols for mobile ad hoc networks are devided into three large classes proactive, reactive and hybrid routing protocols.
Reactive protocols are designed for the ad hoc networks with high dynamics, where the network topology changes frequently. Each time when one node sends a packet to the other node, the routing path is built up again.

Proactive protocols use a kind of routing tables. It is assumed that the routes change not so often and they can be saved for a while in a table. The tables are then changed by the nodes.

Hybrid protocols use both of these technics.

The list of most popular algorithms can be found for example in Wikipedia.

Transport Layer.
In most ad hoc networks various realizations of TCP are used as the transport protocol. All the realizations like TCP Reno, TCP New-Reno differ from each other by algorithms that set the congestion window. The “normal” TCP doesn’t work well in ad hoc networks because the packets are frequently lost being propagating over the air. “Normal” TCP has to be adopted to these conditions.

Application Layer.
Unlike the Application Layer in common networks, application layer in mobile ad hoc networks can’t be completely isolated from the network layer. The developing applications have to be aware of the dynamics of the network and depending on the frequency of the topology changes apply for example the appropriate routing protocol.

Classification of Mobile Ad Hoc Networks

connectedDevicesWhat is a Mobile Ad Hoc Network? It is a collection of mobile nodes, such devices as PDAs, mobile phones, laptops etc., that are connected over a wireless medium. Thee is no pre-existing communication infrastructure (no access points, no base stations) and the nodes can freely move and self-organize into a network topology.

Such a network can contain two or more nodes. Every owner of a mobile phone equiped with a bluetooth module can build up a direct connection to the other phone and exchange data. It’s the simpliest form of an ad hoc network, one hop piconet. Only one hop is actually not so exciting. Mobile multi-hop ad hoc networks are much more interesting. There are three classes of such networks.

  • MANets – Mobile Ad-hoc Networks. It”s the classical ad hoc network that came from the military sector. These networks were developed to connect planes, tanks, troops at the battlefield. They are completely self-organizing. The other possible areas where they could be applied are disaster recovery, car-to-car communication, home networking. This class of ad hoc networks can be seen as the forefather of the other classes.
  • WMN – Wireless Mesh Networks. Like MANets, but there is a set of nodes, stationary mesh routers which form a wireless multi-hop ad hoc backbone. The mesh routers can be connected to the Internet and thus all the participants of the backbone have an access to the Internet. Imagine you are at the airpot where there are only few access points (mesh routers). You have no direct contact to a one, but still you have an Internet access due to the other guests of the airport. The mesh routers make the routing task more simple and the protocols running on them allow the backbone to be easy to set up and self healing.
  • WSN – Wireless Sensor Networks. This special class of ad hoc networks is used to monitor some phenomenon in a certain area. The nodes have often only the simple task to deliver the monitoring information such as measured temperature, air polution, median speed of the cars on a highway etc. to the minitoring system. The devices partitipating in a sensor network are just special sensors that differ greatly in their purpose from the user devices. Thus the solutions designed for the general multi-hop ad hoc networks where mobile devices execute such applications as Skype, instant messaging, streaming applications etc., just don’t suite for sensor networks.

The idea of ad hoc networks is not that very innovative. It’s almost as old as the Internet. In the last years the interest to the ad hoc networks has grown very much. Especially in the car and entertainment industry.

PolterApp Version 1.7

PolterAppHeute Abend ist Version 1.7 der PolterApp im App-Store erschienen. Wie angekündigt bietet die neue Version das Holzaufnahme-Verfahren “Einzelstamm” an. Damit unterstützt die PolterApp nun die drei wichtigsten klassischen Holzaufnahme-Verfahren Schätzung, Sektionsvermessung und Einzelstamm-Erfassung.

Bevor es mit der Entwicklung anderer Verfahren nämlich Mantelmaß und Fotooptische Holzvermessung weiter geht’s, wird die PolterApp etwas  in Sachen Usability und User-Experience verbessert. Diesem Thema werden die nächsten 1 bis 2 Releases gewidmet.

Einzelstammaufnahme. Aktueller Stand

PolterAppDie Arbeiten am Einzelstamm-Holzaufnahmeverfahren sind im vollen Gange. Dank dem flexiblen Datenmodel der PolterApp und sauberer Software-Architektur ist Integration neuer Messverfahren eine einfache Angelegenheit. Das neue Update der PolterApp ist gegen Ende nächste Woche zu erwarten. Auch dieses Holzaufnahme-Verfahren wird dauerhaft kostenlos zur Verfügung stehen.

HockeyApp in a praxis

hockeyapp_logoHockeyApp is a solution for collecting app crash reports, get feedback from users and distribute your betas. It can be integrated with apps for iOS, Android and Windows. This week I had an opportunity to evaluate it and now want to deal with my experience.




  • Integration into an iOS app is really easy. Using Cocoapods it’s just one entry in your podfile:
    pod 'HockeySDK', :subspecs => ['AllFeaturesLib']

    Be sure to enable AllFeaturesLib if you need a feedback functionality.

  • To start using HockeyApp in your project, you first need to register the app under your HockeyApp account. After doing that, you get an identifier for your app. This one you’ll need in your project
  • With these lines of code you initialize HockeyApp and get it running:
    [[BITHockeyManager sharedHockeyManager] configureWithIdentifier:@"yourHockeyAppAppId";
    //you can add the following line before calling startManager to disable the In-App-Update feature
    [[BITHockeyManager sharedHockeyManager] setDisableUpdateManager:YES];
    // Do some additional configuration if needed here
    [[BITHockeyManager sharedHockeyManager] startManager];
    [[BITHockeyManager sharedHockeyManager].authenticator authenticateInstallation]; // This line is obsolete in the crash only builds
  • From now on all crash reports appear  automatically at the backend side
  • To integrate a feedback form  just build in two buttons into your app with corresponding handlers:
    - (IBAction)composeFeedbackAction:(id)sender
        [[BITHockeyManager sharedHockeyManager].feedbackManager showFeedbackComposeView];
    - (IBAction)feedbackListAction:(id)sender
        [[BITHockeyManager sharedHockeyManager].feedbackManager showFeedbackListView];
  • At the backend the administrator can view user feedbacks and reply them. In the app the user gets automatically notified about new replies.
  • Integration with Jenkins is also a matter of a few minutes. There is a plugin for uploading .ipa files to the HockeyApp. Depending on your needs, this Jenkins-plugin can release the app version immediately into a download area of the HockeyApp. The download area can be accessed then by beta-testers or if you define also by a public.

All in all HockeyApp is a pretty helpful tool. Maybe it’s not a suitable solution for individual developers because of the pricing model, but for companies it can be an attractive alternative.


End of the story for Microsoft Band

Microsoft BandAccording to numerous rumors there might be no follower for Microsoft Band 2. This is still not officially confirmed by Microsoft, however, this seems to be only a question of time.

Personally I cannot really follow this strategy step of Microsoft. Weak market? This is the only explanation I can think of. Yes, Microsoft Band 2 is not perfect. But still it has its fans. Currently, its the only device on the markt with such a wide range of sensors.

I had also an opportunity to play a bit with its SDK. It makes a pleasant impression. The only shortcoming I can point on is the way for accessing the health data. It is only possible to access the data in real time. There must be always a bluetooth connection between your iPhone/Android/Windows  app and the band, during the native “Microsoft Band” app can access the internal memory of the band and read data stored on it.

If the next generation of the Microsoft band had been extended by an interface for accessing the data stored on the band, it would make it to an attractive wearable. At least from the app developing point of  view.

PolterApp Versionen 1.5 und 1.6

PolterAppPraktisch hintereinander sind zwei Updates erschienen, Versionen 1.5 und 1.6. Es handelt sind dabei um reine Fehlerbehebungen. Insbesondere gab es Probleme mit Fotos. Die PolterApp stürzte während Fotoaufnahmen ab. Nun sollte alles wieder in Ordnung sein

PolterApp Version 1.4

PolterAppVersion 1.4 der PolterApp bringt ein neues Meßverfahren mit, nämlich Schätzverfahren. Wie die Sektionsvermessung steht auch dieses Verfahren ab sofort kostenlos zur Verfügung. Umsetzung weiterer Meßverfahren Einzelstammerfassung und Mantelmaß ist bis Ende des Jahres eingeplant.

Des Weiteren wurden diverse kleine Fehler in der PolterApp behoben. Insbesondere ist die neue Version 1.4 komplett iOS 10 kompatibel.