We’re happy to announce that we will begin the beta phase for Unified Remote for iOS soon. We are currently looking for beta testers to help us prepare the app for public release. Visit our beta sign up page for more details.
For V3 we’ve invested some time into improving the core functionality of Unified Remote. One of the most used features is Basic Input (mouse and keyboard) control for your computer. To make this better, we’ve added a new keyboard bar that lets you access the special keys on your computer, in any remote. The keyboard bar shows up automatically when you open up the standard keyboard on your device.
Besides adding an extra keyboard bar, we’ve also added a media bar. The media bar shows up by pressing the “media” key in the button bar at the bottom of the remote (the music symbol). This gives you quick access to basic media keys, and system volume control, in any remote. So now you’ll be able to control your music/video playback easily from anywhere in the app
Navigation is one of the biggest changes we’re making in the new V3 app. Our aim is to make it easier and faster to navigate around in the app. We decided to go for the popular side menu design which combines the dashboard items and a quick change server list. The menu can be accessed from any remote. We’re also adding other features to make it even easier to navigate around in the app.
Hi everyone! It is time to start showing you what will happen in version 3 of Unified Remote for Android . We will post about one image a week until we begin beta testing. We are looking forward to receiving a lot of comments on these images since this is the best time to influence the design and feel of the new version.
This week we will start with the basics and show you the updated remote view. We’ve integrated native Android tabs into the remote now. This makes it easy to swipe sideways to switch between tabs in a remote. We’ve also added some new action bar icons. More about this later!
The last couple of posts have been all about the server and all the amazing things that version 3 is bringing to the table. But the thing that most of you actually care about is the app. This post will therefore be about that and the big features we are currently working on.
The first feature is IR. We have had support for a small amount of IR blasters in Version 2. But they have always been targeted torwards advanced users. In version 3 and in some parts in version 2 we will try to change this. The goal is to support a large number of IR blasters and also make it easy for all users to create remotes that use IR. We have already added support for HTC and Keene in the app and as a BETA we also have support for Samsung devices (more info see this link https://groups.google.com/forum/#!topic/unified-remote-beta-testing/YC_Dkw1MR_o). The problem with Samsung devices is that they are not able to learn IR codes and we have not found a good database for IR codes that we are able to bundle with the app. This makes it more difficult to use Samsung devices. We hope to provide support for more IR blasters in the future.
One of the biggest features in the new v3 server is how creating remotes has been improved and all the new advanced things you are able to do with them now (using Lua). But not all of you know how to develop remotes since there is a bit of a learning curve. We have also noticed how a lot of users have embraced widgets and the new Quick Actions. But there have been some problems with them that makes it a bit frustrating to develop. We have started to make some improvements so that everyone is able to make Widgets and Quick Actions more easily.
At the same time we thought that remotes are the most important thing in Unified Remote and everyone that is able to make a widget or Quick Action should be able to make a custom remote too. That is why we have started on a custom remote editor. It will have a “wsiwyg” editor that will allow you to make layouts.
We have also begun work on a new action builder. That should make it faster to find the action you need in your remote. From this action builder users with IR blasters will also be able to build remotes. Both remotes that uses the built in or network connected IR blaster and remotes that uses USB connected blasters connected to the server computer.
We hope these changes will make it easy to customize Unified Remote for your needs. You will see updates with these features in the coming months. If you think we have missed something please tell us know in the comments.
We are very excited to announce that the DP1 release of the new server is now available. We are currently looking for users who are interested in helping us test the new server, especially with compatibility on different operating systems. Note however, that this is a very early release, and will contain bugs and untested features.
Please use our Beta Testing Google Group for all support, bug reports, crashes, requests, improvements, suggestions, or anything else regarding the new server. Please do not use our regular support and request sites for V3 issues.
To get started, click the link below
The blog has been quiet for a while mainly because we have been working non-stop for the past few weeks with many new features. This of course includes the work we are doing on the next major release of the server (version 3). Many of the core features have been implemented now, and we have been testing and adding functionality for Windows, OS X, and Linux. We feel that we are beginning to reach the first public release of version 3, which will be a Developer Preview (pre-beta) release. This will mainly be targeted towards users interested in beta testing and those who want to begin trying out the new scripting functionality.
Who can test DP1?
Anyone who has the full version of the app.
When will DP1 be available?
Our current goal is to release by the end of this week.
How will DP1 work?
DP1 will be released as command-line only (i.e. no graphical user interface).
Will DP1 be backwards compatible with the V2 app?
Yes. You will be able to use the current app (available on Play Store and WP Market) to test the new version of the server.
What OS will DP1 run on?
We will initially release for Windows 7, OS X Mountain Lion (10.8), Ubuntu 12 and/or 13. Other versions of these operating systems will most likely also work, but we won’t be testing for those yet. We will also only be targeting x86 and x64 initially. ARM support will come later (i.e. for Raspberry Pi).
Which remotes will be available?
We have converted more than half our the current V2 remotes to V3 for Windows. This includes the “simpler” remotes, for example those that mainly use keyboard shortcuts. We are slowly adding more advanced remotes as we implement more scripting functionality. We have not begun creating/testing remotes for OS X and Linux yet, but we hope to release some example remotes in DP1.
What scripting features are implemented?
As described in earlier posts, V3 remotes will be based around Lua scripts. This provides a lot of functionality by itself, but we are also building a library of common functionality. This library is slowly growing as we add more features that we need as we convert V2 remotes to Lua. DP1 will have support for the following libraries:
- Device Actions
- FFI (call C APIs)
We are currently working on a new feature called Quick Actions, which allows you to configure a custom notification containing remote control buttons for easy access. It basically works just like the widgets, except it sits in your status bar.
The idea is that once you start the app for the first time, the Quick Actions notification is added to your status bar. Since it is the first time, you will be prompted to configure quick actions (or disable it if you don’t want to use the feature).
Clicking the button takes you to the Quick Actions configuration activity. It works just like the Widget Editor, except some features (such as background color and text) are not supported. You can also disable the Quick Actions feature from there.
The configuration activity will be accessible from the main app preferences as well, which is useful if you wish to re-enable the Quick Actions featured if it has been disabled.
The configuration activity lets you add/remove your buttons, with different actions and different actions. Once saved, the new actions will be available from the status bar immediately. Extremely useful for your most used actions, since they’re always at hand, regardless of what app you’re using.
The notification remains in your status bar until you either force Unified Remote to exit, by tapping the “Exit” button on the dashboard, or by disabling the quick actions all together.
We plan to release this ASAP, in the next regular update (v2.9).
We have been making good progress with version 3 over the past few months. One of the most important milestones we have reached now is that we have basically decided how remotes will work in version 3.
For version 3 we have taken a “package” approach for remotes. Every remote consists of a script file (programmed in Lua) and an optional Layout file (using XML). Including full script support will open up a lot of new possibilities for custom remotes, but also enables us to release all of our remotes to use the exact same format that custom remotes will use.
Recently we started the process of converting all of the remotes from version 2 into the new format that will work in version 3. We thought now would be a good time to explain how the new remotes will work, and outline some of the capabilities that version 3 brings.
One issue we have in version 2 is that there is no real definition of a remote’s life cycle. This is fine for simple remotes that are state-less, but becomes problematic when implementing more complicated remotes that require initialization and cleanup. One of our goals for version 3 was to make the remote’s life cycle clear and simple:
- Preload: occurs when the server starts up and the remote is detected and registered in the server. Preloading does not mean that the remote should fully initialize, but rather mainly used for generating dynamic layouts (i.e. layouts that are generated using code, rather than in an XML file). Preloading should be quick and only used when absolutely needed.
- Create: occurs when the remote is created for the first time (i.e. when opened in the app for the first time). Create should be used for basic initialization that is required for the remote’s functionality.
- Focus: occurs when the remote comes into focus (i.e. when it becomes active and is being used by the app). Focus should be used for starting state updates (such as fetching the current playing song from a program).
- Blur: occurs when the remote goes out of focus (i.e. when the app no longer uses the remote). Blur should be used for stopping state updates that were started in Focus.
- Destroy: occurs when the remote is destroyed and is no longer in use. This occurs when the server is stopped or the server decides that the remote is no longer in use. Destroy should perform all clean up.
The Lua script file is the main and only required component of a remote. It provides some meta information (such as name, description, etc), some standard functions for the remote’s life-cycle, and the actions that the remote will perform. The basic structure of the script file looks like this:
-- Metadata (required) meta.id = "Unified.Foo" meta.name = "Bar" meta.author = "Unified Intents" meta.description = "Foo bar remote control." meta.platform = "windows" -- Standard remote behavior (optional) remote.preload = function () ... end remote.create = function () ... end remote.focus = function () ... end remote.blur = function () ... end remote.destroy = function () ... end -- Actions for the remote (optional) actions.foo = function () ... end actions.bar = function () ... end
The layouts file is an optional file that can be used to define the visual layout of the remote. For most remotes, this is the preferred way of creating the layouts, rather than generating them in the preload function. The syntax is almost identical to the syntax used for custom remotes in version 2.
<?xml version="1.0" encoding="utf-8"?> <layout> <grid> <row> <button text="Foo" onTap="foo" color="red" /> <button text="Bar" onTap="bar" color="red" /> </row> </grid> </layout>
The actions are what couple a layout and a script. A layout can easily call the actions defined in the remote by referencing them in events (such as onTap in the layout above). The action in the script then performs whatever tasks it needs to do to perform the action.
For those of you that aren’t familiar with Lua, it is a very lightweight but very feature rich programming language http://www.lua.org/. One of the reasons we chose to use Lua for the script files is that it is very flexible and allows you to essentially implement whatever actions you like. The standard Lua library provides basic functionality for executing processes, file system IO, math, etc. You can even call external C APIs. We’ve also implemented some standard libraries for simple actions, such as simulating key-strokes or fetching the title of a Window.
Hopefully this provides some insight into how remotes will work in version 3. More information and examples will come in later posts. Stay tuned!
When we started with Unified Remote we had no idea how big it would be and what problems our users would have when using the Unified Remote. But very soon after the release it was clear that we would need some way to handle support and bugs.
In the beginning we only had e-mail support, which we quite soon discovered was not ideal when trying to give support to multiple users at the same time. It was also impossible for users to find answers to problems that other users already had asked about and got resolved. This meant that we had to answer the same question more than once and this increased the workload.
To make it easier we created a forum using phpBB where we hoped users would help each other, which in many cases happened. But there was two big drawbacks to the forum solution. First of all phpBB is a very popular system used by many sites, which unfortunately caused a lot of spam. The other problem was that we did not know the system that well and we did not like to spend time learning it, when we could spend our time with more fun things, such as Unified Remote. In the end we closed the forum.
Now we have two support solutions, e-mail and our support site at support.unifiedremote.com. We developed the support site in-house to make sure that there wouldn’t be any spam bots. We think it has worked very well for the most part but there has been one thing missing. That is when a user reports a bug we did not have any good way of recording it. We tried to use Google documents and lists but they were not good enough and took to much time to keep updated and synchronized.
Now we have what we hope is the solution for this. About two weeks ago we started using a system called YouTrack developed by JetBrains. It is an issue tracking system and we think it will work a lot better than all our old solutions. But there was still one problem. When a bug was reported to us we still had to create an issue and that meant opening YouTrack and copying the support ticket information. What we needed was a solution that allowed us to create the issue directly from the support ticket. Luckily YouTrack has an excellent API. So we have now integrated the issue tracking system with our support page.
Now we have the ability to create issues and make comments to existing issues. In the future we are planing to add a function that automatically updates the support thread with new comments and event notifications when we change something in the YouTrack issue. For example if the issue gets fixed or updated.
We hope that this will help us fix reported bugs faster and better, and also provide higher quality support in the future. But even with all these new great tools we are in the end only two people behind Unified Remote, and we do everything in our spare time (lots of work!).