

DSR is happy to announce that ARM has chosen DSR ZigBee 3.0 stack to support their new product, ARM® Cordio® radio IP. ARM® Cordio® radio IP belongs to the ARM family of 802.15.4 and Bluetooth 5 standards-based low-power wireless IP solutions. It provides a complete RF-to-Application solution for WPAN (Wireless Personal Area Networks) radios.
ARM reckons Cordio radio IP is the only fully integrated platform in the market and includes a transceiver, baseband, and link layer (LL) subsystem including firmware. Moreover, ARM claims devices using Cordio radios will last up to 60 percent longer between battery charges due to falling under the typical wireless circuits that run at 1.2 volts.
ZBOSS 3.0 – ZigBee 3.0 stack from DSR is now offered as the stack of choice for those willing to utilize ZigBee on top of the Cordio radio. Built with great attention to a fixed memory footprint, ZBOSS also provides optimized power consumption, making the end device last even longer.
More information about the ARM Cordio can be found here: https://www.arm.com/about/newsroom/arm-accelerates-secure-iot-from-chip-to-cloud.php.
For additional information about ZBOSS 3.0 ZigBee Stack, please visit: http://www.dsr-zboss.com/#!/.
DSR is an end-to-end IoT partner and is always ready to support your IoT solution. Feel free to contact us with any inquiries at contact@dsr-company.com.
DSR understands that open source community is what pushes the modern IT world forward. DSR is well known for ZBOSS, ZigBee® open source stack certified by the ZigBee® Alliance. Moreover, DSR continuously contributes bug fixes for issues found during development with various modern development platforms and technologies.
DSR understands the value of sharing tools, standards and best practices that we use internally. So recently DSR team released a Yeoman generator for AngularJS. It has some useful optional features, like JWT support, basic components, tools for responsive UI and some others, and, of course, good documentation. The source code is available here:
https://github.com/DSRCorporation/angular-generator/
This is only the beginning. Soon we’re going to release a Yeoman generator for Node.js, several advanced AngularJS UI components and many other fancy things. Stay in touch and sign up for our newsletter to get the latest updates from DSR or check out our blog.
Not too long ago Bluetooth® SIG announced that Bluetooth® is going mesh, giving a rise to a new wave of interest to Mesh networking. Although the interest is growing rapidly, solutions available on the market keep using just the trusted star topology. But what are the real possibilities?
Most networks on the market are declared to be “mesh ad hoc,” so in most cases these terms are used together in turn blurring the difference between them. But there is a difference and it’s important to highlight it.
Mesh network is a kind of a network topology where all the possible connections between nodes are established. This leads to the main mesh network feature – self-healing, where broken routes can be restored using different access links between devices.
Ad hoc network is a decentralized wireless network that does not require any infrastructure to form and maintain. Nodes connection depends on its possibility. This network is self-configuring, which means that devices can join or form it on the fly.
In this way, mesh network is the most robust static type of ad hoc networks. But when both terms are used together, they typically mean ad hoc only. Mesh explains just the physical layer of wireless communication that is broadcasting from its nature where all devices that are close enough hear each other (i.e., connected) and form enough links for self-healing. To be completely accurate, it should be mentioned, that “ad hoc” means that the nodes are stationary. There is a term for mobile nodes – Mobile ad hoc networks (MANET’s). But today in PAN/LAN context (Wi-Fi, Bluetooth, ZigBee) nodes are assumed to be static due to their use cases, even if they can be moved sometimes from place to place.
Wi-Fi is an area that already has ad hoc solutions available through documents and open source. Official specification IEEE 802.11S is the less effective and innovative one. It introduces two new kinds of devices: Mesh portals and Mesh points. Mesh portals are ordinary Access points with wired connection to the Internet. Mesh points act as wireless routers between stations and portals. Everything that has “mesh” prefix is connected together where it is possible. The standard is completely the same as B.A.T.M.A.N. adv Wi-Fi mesh that is already included in the Linux core.
In parallel, open source community works on cjdns (Hyperboria) that is a real candidate for the DarkNet set of protocols. Cjdns is developed in the way to create a wireless mesh network that is totally disconnected from the Internet. Its core advantages are:
The last one is a headache for all Wi-Fi ad hoc networks. Old DHCP conflicts with the essence of the ad hoc network and mobility.
Mesh networking using Wi-Fi sounds ready but not for small low-power devices. Thus, we better pay attention to Bluetooth® Low Energy (BLE) and ZigBee®.
The first thing that Mesh-network-sceptics say about Bluetooth® is that it was not designed for Mesh networking. However it is widely spread, so why not to try using it?
Existing solutions on BLE are nothing more than trying to sell things that we already have in ZigBee® under the “Mesh network” label. To build a “mesh” the customer should buy a BLE gateway that forwards packets to the cloud. All main-powered BLE devices act as routers and interconnected with each other, while battery powered devices talk to routers only. Nothing special.
But BLE wins in that it is already in devices that have the Internet connection through 3G, LTE, Wi-Fi, and even the cable. That means that in theory the customer can get more than one gateway connected by the Internet. Moreover, customer’s tablets and smartphones bring the mobility to such network.
The power of the Wi-Fi + BLE collaboration has already been explored by Apple: check out the Multipeer connectivity framework for iOS 7 and, for example, FireChat application that proudly announces “Internet is not needed to chat.”
When talking about ZigBee® one thing should be kept in mind – it was initially designed to be ad hoc. The routing mechanism implemented in ZigBee® is called Ad hoc On-Demand Distance Vector (AODV). Although RFC is operating IP frames, there are no major differences. The algorithm is quite simple for CPU and gentle to ROM and is available even for a bulb or smart socket or any other main-powered device.
As it was mentioned earlier, ZigBee®-based systems on the market currently prefer to use star topology, even though it has everything to be a mesh network and should be used as such. When Wi-Fi or BLE implement mesh, it is not only a technological step forward, but a marketing reason. The truth is ZigBee® is already a step ahead in terms of technology, but maybe a step behind in terms of marketing.
One might mot like that ZigBee® network is not using IPv6. Well, neither does BLE, but it does not disturb it. Nevertheless, there is IEEE 802.15.4 + IPv6 + UDP solution called 6Lowpan and Thread or JupiterMesh built over it. Though they haven’t still made a splash on the market, probably nobody has positioned them as “mesh.”
As we can see, if the market wants mesh/ad hoc/MANET, there are all the pre-requisites for it. It is already around but the customer is not aware of it because either the market is too “shy” or that field has not yet been covered in depth. Anyway, the results will come soon and they will come from Wi-Fi, BLE, ZigBee or even a collaboration between them.
No one will argue that IT is one of the fastest developing areas of engineering. New tools, approaches and ideas complete or even supersede the existing ones. One of the quickest growing technology stacks is the Scala language stack. In this blog we explore what makes this language awesome.
Language Design
Scala was designed to help write thread safe and laconic code. It overcomes some JVM limitations and provides features that could not be achieved in Java. Scala has a clean, expressive, and extensible syntax with lots of built-in shorthands for most common cases.
Since less code needs to be written to accomplish the same task, the programmer can now focus on the problem’s solution instead of spending the time for boilerplate code. It is especially nice if you pay your programmers for SLOC. Furthermore, Scala reduces the number of places mistakes can be made and hence improves implementation quality.
Here is a short list of Scala language and compiler features:
val i = 1 // Int
val s = “Hello, world!” // String
class Point(x: Int = 0, y: Int = 0)
new Point(y = 1) // Point(0, 1)
users.filter(_.lastVisitDate before today).map(_.email).foreach(sendNotification)
// Sending notifications to all users that visited our site too long ago
val sum = sumActor ? List(1, 2, 3) // sum == Future(6)
val x = sum.map(_ * 2) // x == Future(12)
Distributed Computations and Big Data
One of the fields where Scala found its widest application is distributed computing. Scala has great mechanisms for working with data sequences even in a cluster, which is why it is frequently used by Big Data engineers and data scientists. Here is a list of the most well-known technologies that use Scala:
In addition to these tools, it is also possible to use Scala for implementing good old Hadoop map-reduce jobs, directly or utilizing Scalding. Anyway Scala is a great choice for data processing and distributed computing.
Compatibility with Java
One more important thing is compatibility with libraries written in Java. Java code can be used in Scala directly and without limitations. This allows to keep existing modules without the need to re-implement them. It could be quite helpful when it is needed to use a rare library, legacy code, or API that have implementations only for Java.
Why Scala?
To sum it up, Scala is well designed and very extensible. It has special processes (SIP and SLIP) that let any Scala developer propose enhancements. In conjunction with the large community, Scala ecosystem has been growing rapidly. Scala has its own stack of tools and is compatible with existing Java code. It brings new effective approaches that give the programmer an ability to do their job more efficiently. All these features make Scala one of the most attractive modern programming languages.
Contact us at contact@dsr-company.com to learn more or if you have a Scala project to discuss.
The coming transformations in the media distribution space provide ample opportunity for both vendors and operators to work together to improve efficiencies and increase user satisfaction on the consumption experience.
DSR believes that after the failure in uptake on in-home 3D, the media & entertainment market is primed for the success of the next wave of consumer experience improvements, which we believe will be driven by high dynamic range (HDR) video, continued over-the-top streaming distribution (including 4K video resolutions) and virtual reality. Beyond the consumer experience, the backend of media operations can be substantially enhanced and prepared for these changes by embracing IMF, IP ingest & playout and virtualization of media processes.
As a software engineering provider for media & entertainment vendors for more than a decade, DSR is uniquely positioned to provide our expertise in building applications and backend services to assist companies ready to embrace these transitions.
Consuming video wherever, whenever has become mainstream, and enabling those consumption habits has increased the workload on media transformation by several times in the last 5 years. IMF (a SMPTE standard for Interoperable Media Format) finally holds a promise to simplifying versioning for this wide array of consumer consumption channels.
IMF can simply your media workflows by using a single package to hold an original version video, along with all possible substitutions and exclusions referenced by composition play lists (CPL). Since additional CPL are just XML documents and substitutions and exclusions are much smaller than creating new additional versions for each distribution point, IMF not only promises simplicity in distribution, but also a possible reduction in media storage.
Within IMF, it is also possible to handle 4K video and coming soon, high dynamic range (HDR) content, along with downmix instructions, so that a single file package can hold the true master content, as well as the recipes for creating premium and lower cost versions.
DSR has already built tools for customers based upon IMF parsing, packaging and file playout, and we can bring that expertise to your project as well.
Consumer appetites for new and exciting video experiences appear to be increasing, and virtual reality experiences are poised to fulfill those desires. Several challenges exist in preparing content, however, including:
DSR’s wide array of experience in handling video for ingest and playout puts us in a position to help advise and create applications within the virtual reality space, particularly when dealing with video and audio layouts.
In the last several years, DSR has helped many of our clients migrate and manage their applications from on-premise deployments to virtualized deployments, both on the cloud and in local datacenters. Our knowledge of multiple hypervisor technologies allows us to be agnostic in helping our clients migrate applications.
DSR has a wide range of expertise in refactoring applications, removing tight couplings between user interactions and data processing to enable the addition of web services. Our database expertise and API knowledge also helps speed the transition of applications from those dependent on single machine processing to those that can scale between multiple virtual machines.
Whether your organization is facing the challenges of:
DSR stands ready to help. We have over 10 years of experience in media & entertainment applications, working with enterprise application vendors and start-ups, with a stable team of engineers that understands video, audio, captions and containers (and English). Let us bring our engineering team to help in your next project.
Contact us at contact@dsr-company.com
At the end of last year, a group of researchers from Cognosec presented their “ZigBee exploited” report at the BlackHat conference in the USA. They demonstrated a tool that allows an intruder to open your doors, shut up motion sensors off and even turn the lights off in your bedroom, of course only if these devices are controlled via ZigBee. IT and for the most part non-IT sources repeated the news many times with excessive drama effect and as a result, we had got a categorical accusation of lack of security in ZigBee and even the entire IoT. Based on the forecast that there will be 29 billion of IoT devices in the not so far 2020, “experts” convinced their readers that it is not the problem of the future but the present and that all devices are vulnerable. Now when the panic has calmed down, let’s see what happened in terms of ZigBee.
First, let’s talk about silent motion detectors. Motion detection in the system that was hacked works the following way: when a sensor detects a movement it sends a ZigBee message to a gateway (you may call it smart hub, ZigBee hub, etc.), which uses TCP/IP to deliver this message to the user. Cognosec researchers used a jammer to break the ZigBee link between the sensor and the gateway. Even when the jammer had been turned off, the motion alarm was not retransmitted because the retransmit attempts were over or the sensor decided that the link was lost (we can only guess). Samsung, whose hub was attacked during the research, has already given the proper comment and we agree with it 100%: ZigBee Motion sensors are not designed to be a professional, highly secure alarm system. We wonder if anybody has already seen a professional alarm based on a wireless protocol. Although the jammer attack is not specially a weakness of ZigBee, it may be useful for those customers, who want to get an alarm but do not want to pay a high cost.
Moving on, now we are going to discuss the weakness that was introduced as a supermassive hole in the ZigBee security, but it is actually not ZigBee specification’s fault. The reality is that a large number of ZigBee devices available on the market use the default Trust center link key to encrypt active network key transport. This key is open and there is not much difference for security in sending the network key as plain text or encrypted by the default key. ZigBee specification warns developers about such threat and recommends out of band or not-by-the-air methods to deliver an initial master key to both the trust center and the device. Researchers criticize this recommendation because it is not a requirement when the required by the specification default trust center link key in its turn breaks the security. But why shouldn’t the not in-band key delivery be a part of wireless protocol specification? Moreover, as anybody, even researchers, agree, unsecured key transport is ideally performed only once, during an association and most likely is not a threat, of course unless a maniac with an enabled ZigBee sniffer is spying on your house 24/7. And here the thing that everyone is talking about comes to the surface. Assuming that a quick, low-power, unsecured key transmission is performed once, hackers enable their jammer again to force link loss. When the link is lost, there are two ways to get the key:
Respectively, there are two ways to dispute:
The main conclusion from our dispute is that the found exploit is not a “ZigBee” one, it’s “Current ZigBee implementation exploit.” It will not be superfluous to say that researchers from Cognosec are ZigBee users too and they pointed out that ZigBee specification provides all the good recommendations to build a secure system. But dramatic headlines and maybe mass hysteria turned the device problem into the core standard one. There won’t be any panic, if anybody interested in IoT (or ZigBee), based their opinion on the original source:
Fast, convenient, tricky. These are the first three words that come to mind if someone asks how it feels to develop with Angular Material. The project’s documentation states the following right on the first page: “For developers using AngularJS, Angular Material is both a UI Component framework and a reference implementation of Google’s Material Design Specification. This project provides a set of reusable, well-tested, and accessible UI components based on Material Design.” Let’s take a close look at whether it is 100% true based on our extensive experience of developing SPAs with Angular Material here at DSR Corporation.
Well, let’s drop all these subjective metrics and talk features:
As its name suggests, Angular Material implements Google’s Material Design Specification. So if you want to follow Google’s guidelines you’ll find that many things work right out of the box as expected. Just keep in mind that this is one of many ways to implement it. Get ready to be flexible in your design and to alter it in favor of keeping your code clean. With great power comes great responsibility. With many built-in features, directives, services, animations, and CSS’ rules comes a hard-to-modify predefined behavior. We are not saying it’s impossible to change the way things work in Angular Material, but it would take another dirty hack to do it.
After all, convenience is a very subjective thing so here are some key features that should make your life easier:
Here comes a fly in the ointment. Since Angular Material is pretty young, it has all expected “puberty” problems. At the moment of writing this article it has 1545 open issues and 90 pending pull requests. That’s for a good reason: as long as it works fairly good under Chrome, it starts showing teeth under Firefox and constantly fails here and there under Safari, especially mobile Safari. If your target platform is Mac OS, you still can keep your code more or less readable, but cascade of hacks can bring your app to its knees in case you must make it work under OS X. Not to say that it’s not going to work in the end, but you will have to sacrifice some built-in features or spend hours making custom overrides, which kind of undermines the whole idea behind using Angular Material.
To sum up all of the above we can say that Angular Material is a promising powerful tool that can help you a lot and drastically improve your performance. Just keep in mind its current limitations and issues in order to not build an unmaintainable monster.
If you would like to learn more, have a project in mind, or want to share some comments, please connect with us at contact@dsr-company.com.
Today there exist two standard ways of providing video content – “video on demand” and “live streaming.” “Video on demand” assumes that a client requests static media content from a server. “Live streaming,” means that media content is generated real-time and translated through a server to several clients.
In addition, media consumers use multiple types of devices for both ways of video playback:
To cover most media traffic accessed via different methods and by different types of devices, it is important to cover the formats and technologies that make it possible.
MPEG-DASH is Dynamic Adaptive Streaming over HTTP (DASH) technology that evolved since 2010 and was adopted by main hardware vendors and content providers. In 2016 this technology overpowered the Adobe Flash Player widely used in desktop browsers for media content playback, since all mainstream desktop browsers support MPEG-DASH.
The challenge remains for mobile devices and Apple TV that still do not support this technology well and primary use HTTP Live Streaming. Several custom MPEG-DASH implementations already exist for the main mobile platforms on the market, but it is not yet included in the native SDKs.
MPEG-DASH is format and codec agnostic, but currently the following formats and codecs are mostly used:
h.264 codec is well supported by software and hardware chips and it can be definitely the best choice today, but it imposes royalty fees if the provider charges customers for content.
VP8/9 is royalty free, but doesn’t have as wide of adoption as h.264, so it should be carefully checked if a particular target platform supports this codecs.
HTML5 UI that can be run from any mainstream browser is the most modern way to playback media content for desktop end-users. HTML5 standard provides special <video> and <audio> elements for native media playback support, but it works natively only for the “video on demand” approach. MP4 is supported in all mainstream browsers, while WebM is not supported in Internet Explorer, Microsoft Edge, and Safari.
So far HTML5 doesn’t have a standardized approach for “Live Streaming.” Before the end of 2015 Adobe Flash technology and RTMP (Real Time Messaging Protocol) were widely used to provide live streaming. Now, it is significantly changed. MPEG-DASH now supports all major desktop browsers via HTML5 Media Source Extensions and “DASH.JS” JavaScript library. YouTube and Netflix have been adapting this technology for the last several years and it seems MPEG-DASH has become a De facto standard for desktop browsers live streaming.
The important thing is that native HTML5 “video on demand” approach doesn’t support adaptive streaming. It means it cannot adopt media bitrate in accordance with client Internet bandwidth. This leads to MPEG-DASH technology being used for both “Video-on-demand” and “Live streaming” approaches.
HTTP Live Streaming (HLS) still remains the best choice for both “Video On Demand” and “Live Streaming” approaches for native applications on mobile platforms. Both Android and iOS platforms support this technology with their native SDKs and the stock browsers. HLS works with h.264/AAC codecs on iOS. Android is limited by h.264 baseline level 3.0 profile, but it allows other codecs including VP8/9.
SmartTV, Set-Top-Box and Game consoles usually support a wide range of formats, technologies and codecs. Despite the fact that several technologies cover most media traffic (over 75%), there is no best choice for such devices since it usually is a universal media player for many formats and content providers. Any modern home media device should support the technologies that are covered above without limiting the wide range of device capabilities.
Both MPEG-DASH and HLS can use HTTP/HTTPS as transport protocol. That really simplifies the server side environment. Many HTTP servers support these formats or can be used as proxies to MPEG-DASH/HLS services.
Wowza streaming engine or an exclusive one built on open source software like FFMPEG and MP4Box can be used for transcoding and repackaging.
Both MPEG-DASH and HLS technologies assume streams bitrate adoption to fit client Internet bandwidth. This means that the access point must be able to simultaneously provide streams with different bitrates.
“Live Streaming” requires several encoding processes on the server side to meet the increased sever side hardware requirements, especially CPU core numbers. It may require several modern CPU cores to provide real-time transcoding of a single HD stream.
For the “Video-On-Demand” approach, streams with different bitrates must be prepared ahead of time and stored on the server side. This brings additional requirements for storage size, since several copies of the same original media with different bitrates must be stored.
Any modern media and IP video system must consider most adopted and prominent technologies. Today these include MPEG-DASH, MP4 with h.264, and WebM with VP8/9. HLS is still strong and must be supported, but with MPEG-DASH continuously increasing pressure, it is not unlikely that MPEG-DASH may replace HLS in a few years.
Adobe Flash Player should no longer be used as a main player for any web content provider and it is likely that this technology will withdraw in the near future.
MPEG-DASH and HLS provide great ways for high quality media content services, but on other hand pose increased requirements for content processing and storage on the server side as well as higher complexity of a media system.
Nowadays most people have heard about hybrid mobile app frameworks and their advantages. There are so many of them and each promises everything you dreamed about for a cross-platform mobile applications development. The idea is nice and simple: hosting a web application inside of the user’s smartphone or tablet with the ability to have a single codebase, involve web developers, reduce costs, decrease time-to-market, and so on. However, we can see that most of the mobile applications are still native and platform specific. Why is that? Experienced developers (especially those who had a really hard time working with early hybrid applications) may notice that the real life cross-platform mobile app development process is far from perfect to make it a standard. DSR Corporation team has rich experience in PhoneGap application development and knows all (or almost all) pros and cons of this technology. In this blog we aim to summarize our experience and share the risks that should be considered when using a hybrid mobile app frameworks.
“Like Native” Still Doesn’t Feel Native
After your hybrid application is ready and deployed I bet the first complaint you will get is the performance. The modern day user has zero tolerance for even a slight delay, especially if he or she is expecting to be entertained. Just try to scroll a list in a native iOS application and then in a hybrid one: you will probably not say the hybrid has delays but it feels different and users notice that.
Additionally, if you want to use the same codebase for all platforms, then your application will look the same on all platforms. Sometimes it is good and desirable. Even if it is not, your application will still work fine. But as you may know the UX/UI guidelines are different for each platform and each user base has specific expectations on how apps work on their respective platforms. For example, an iOS user expects a “Back” button everywhere, where Android users may not find the search if you implement it using the iOS style. So when you are implementing the same UI, you are making a compromise or spending extra effort to make it different.
You Can’t Get Away from Debug
If it works on one platform, it does not mean it will work on another. Each hybrid app has its native part and framework development teams work hard to make them work the same way on all platforms so you could relax and concentrate on HTML, CSS, and Javascript. However, even if the framework you picked is “perfect,” each platform is assumed to have its own browser. Moreover, if you extended the native part, for example, by writing your own PhoneGap plugin, you will have to carefully port it to each platform. The situation gets more complicated when dealing with low cost or old devices: each one of them can have its own surprises. In this case you may need to research the Crosswalk pluggable webview (https://crosswalk-project.org/) to make it easier to maintain your app.
As a result, this is actually a normal case for multi-platform development when “write once, run everywhere” turns into “write once, debug everywhere.”
Platform-specific Nuances
In a perfect world a web developer can develop a cross platform mobile app without learning anything else. Meanwhile, using a hybrid framework, please make sure the team is armed with at least the following knowledge:
Keep it Simple
Please don’t expect too much from the hybrids. If you need something of flawless quality or great performance or exquisite look and feel – hybrid is probably not a good choice. Note that hybrid apps are fragile: the more complex architecture you have, the more effort you need to maintain it, especially if this is about interaction of HTML/Javascript part and the native part.
It’s Alive!
Considering the fact that you are still able to use native tools and controls you may think about combining web controls with native ones. Be careful not to create a Frankenstein: the application complexity can rise so significantly that it will become a nightmare to debug and maintain. First, the native control you used will need to be considered on other platforms (there is no guarantee that it will work the same way). Second, the integration part (between HTML/JS and native) is the “richest” source of bugs: the more complex the design is, the more “fun” you will have. Third, thinking about using native controls is a good signal that you need a native application. Consider your options and make the right choice for your app.
The Apple Dependency
Another risk that you may need to consider is a high dependency on the App Store Review Guidelines. The App Store is dominating the mobile apps market, so Apple can and does dictate its rules. The Review Guidelines change quite often and, although unlikely, it’s possible that hybrid apps can get banned from the App Store at some point in the future.
Now when you are aware of the risks you may wonder if there are any reasons for you to use hybrid applications. There are many of them!
Low Cost and Quick Time to Market
If you have a limited budget and need a mobile application, using a hybrid framework may be a solution. Easier UI development will give you a cost advantage even if you are planning iOS as your only platform. Make sure to keep it simple and that your single codebase can be easily ported to other platforms without significant changes. At the same time, reducing your effort can save you precious time, so you can deploy early and have the app ready before your competitors.
Startups and Explore
If you are planning to develop a serious application that requires a lot of effort for UX/UI you may consider prototyping it first. It will allow you to have better understanding of all application usage aspects and resolve problems early. Certainly, your prototype can be a quickly developed hybrid application you can use to get early adopter feedback and demo the concept.
Web Development Forces
If you or your team are good web developers, then you can use your experience in the mobile apps as well. Choose a hybrid mobile app UI framework you like the most and do the main implementation using your favorite tools. In most cases you will not need to learn a new programming language. At the same time, you will be able to develop for additional platforms improving your web development experience.
Better Than a Website
If you are thinking about developing a mobile website instead of a mobile app, then you should consider the serious advantages the mobile apps have:
Although we at DSR prefer to build native mobile apps because of their performance, seamless user interface, and best user experience, we have rich experience building cross-platform mobile apps as well. The latter can give you a serious advantage, but only if the related risks are considered. This is not a silver bullet, but it can be a powerful weapon on your side, if your project meets the parameters described above.
If you would like to learn more, have a project in mind, or want to share some comments, please connect with us at contact@dsr-company.com.