Peter Friese

Peter Friese
Peter Friese arbeitet als Developer Advocate bei Google im Developer Relations Team in London. Er trägt regelmäßig zu Open-Source-Projekten bei, spricht auf Konferenzen und bloggt unter http://www.peterfriese.de. Auf Twitter findet man ihn unter @peterfriese und auf Google+ unter +PeterFriese.
Beiträge dieses Autors

Android Wear: Auf Tuchfühlung mit dem Anwender

Gyroskop, GPS, Schrittzähler, Herzfrequenzmesser, Mikrophon, Magnetometer – was sich wie die Spezifikation für das nächste James-Bond-Gadget anhört, ist nichts anderes als die mittlerweile ganz normale Grundausstattung von Smartwatches.

Robolectric

Testen ist wichtig, darüber herrscht Einigkeit. Regelmäßiges, am besten kontinuierliches Testen führt zu höherer Qualität der Software, frühzeitiger Aufdeckung von Unstimmigkeiten in den Anforderungen und mehr Sicherheit beim Refactoring. Unit Tests sollten mittlerweile zum Standardhandwerkszeug eines jeden Softwareentwicklers gehören.

Android am Arm

Die von Google auf der I/O-Konferenz vorgestellte Betriebssystemvariante für Smartwatches ermöglicht einige interessante Anwendungsfälle. Wir werfen einen Blick auf die Möglichkeiten.

RoboVM – iOS-Apps mit Java entwickeln

„Write once, run anywhere“ – dieser Leitspruch der Sprache Java galt lange Jahre nicht für iOS. Mit RoboVM steht seit einiger Zeit ein Tool zur Verfügung, das es Java-Entwicklern ermöglicht, ihre Sprachkenntnisse auf iOS-Devices zum Einsatz zu bringen – und zwar nativ.

RoboVM – Offen für alle JVM-Sprachen

RoboVM ermöglicht die Ausführung von Java und anderen JVM-Sprachen auf der iOS-Plattform, also beispielsweise dem iPhone oder dem iPad. Es nutzt einen Ahead-of-Time-Compiler, der Java Bytecode in nativen ARM- oder x86-Maschienencode übersetzt. Ohne Interpretationsvorgang kann dieser Code dann auf der Ziel CPU ausgeführt werden, neben iOS-Geräten auch auf Linux- und Mac-OS-X-x86-Systemen. Unser Java-Magazin-Autor Peter Friese sprach mit Niklas über den derzeitigen Stand und die Entstehungsgeschichte des Projekts. Einen ausführlichen Artikel zu RoboVM finden Sie im kommenden Java Magazin 7.2014!

Enterprise Eclipse RCP – Teil 2: Remoting und Caching

Nachdem wir im ersten Teil von Enterprise Eclipse RCP einen Überblick über die Entwicklung von Enterprise-RCP-Applikationen gegeben haben, wollen wir uns in diesem Artikel mit dem Themenkomplex der Kommunikation zwischen Frontend und Backend beschäftigen. Wie bereits im Überblicksartikel dargelegt, gibt es verschiedene Varianten für die Architektur von verteilten Eclipse-RCP-Anwendungen: Client/Server, d.h. der Client greift direkt auf die Datenbank zu, und 3+ Tier, d.h. der Client kommuniziert mit einem Backend-System, das die Geschäftslogik enthält. In diesem Artikel wollen wir zeigen, wie eine Eclipse-RCP-Anwendung mit einer klassischen Drei-Schichten-Architektur umgesetzt werden kann. Dazu zeigen wir zunächst, wie die Kommunikation zwischen Frontend und Backend umgesetzt werden kann. Anschließend gehen wir auf mögliche Probleme ein und zeigen Lösungen hierfür auf.

Eclipse RCP im Test

Java hat zu Unrecht den Ruf, sich nur schlecht für die Realisierung von grafischen Benutzeroberflächen zu eignen. Insbesondere im Unternehmensumfeld wurde in den vergangenen Jahren vorzugsweise auf HTML gesetzt, um Java EE-Anwendungen mit Benutzeroberflächen zu versehen. Eclipse RCP vereinfacht die Realisierung von unternehmenstauglichen Desktopanwendungen. Dies bleibt jedoch nicht ohne Auswirkungen auf die Architektur der gesamten Enterprise-Anwendung.