Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Isaacc7]

With all the announcements from Apple, I wonder what else could be done with the app with iOS 8. It would be cool to have sharing options inside of jremote... Lots of possibilities.

[glynor]

Unbelievable possibilities.

[glynor]

I think some of the continuity features are some of the most interesting when it comes to JRiver applications.  Imagine:

You start a playlist playing at home.
You need to leave.  Tap one button in JRemote, and the Playing Now seamlessly switches over to the iOS device.
You come back home.  Tap one more button, and playback is back on the home theater system.

I'm not even sure how much of the actual continuity APIs they'd need to accomplish this (I'd think MCWS could handle most of that already).  But that is a very interesting possibility.

[6233638]

Rather than proprietary Apple stuff, I'd rather things were changed so that any connected Gizmo clients (JRemote/Gizmo etc.) show up as devices that can be played to/managed from the server, similar to the way that DLNA devices show up once they are available.
 
It doesn't seem out of the realm of possibility to then build "sync with zone…" or "send to zone…" commands to transfer playback status between devices either.
Duplicate the playlist, and start playback at the next track change.
 
I would eventually like to see an implementation that would allow for seamless (as best as possible anyway) switching between devices mid-track, and seamless linking/unlinking of zones during playback, but that would be a lot of work.
But with the id, I'm hoping there are going to be steps taken towards this. If they're looking to compete with devices like Sonos/AirPlay, synced playback is essential.
 
 
Of course these feature could additionally be implemented via Continuity as a one-button command via the lock screen if you have an all-Apple setup with JRemote and the Mac version of MC, but I'd rather things stay as open as possible.

[glynor]

It doesn't seem out of the realm of possibility to then build "sync with zone…" or "send to zone…" commands to transfer playback status between devices either.
Duplicate the playlist, and start playback at the next track change.
 
I would eventually like to see an implementation that would allow for seamless (as best as possible anyway) switching between devices mid-track, and seamless linking/unlinking of zones during playback, but that would be a lot of work.

It wouldn't be that much extra work.  MC saves bookmarks anyway (even on Audio files for which they are ignored).  You'd just need to load the current Playing Now list, set a bookmark, start playback on the device at that bookmark (seeking), and then issue a stop command to the server.

I don't know the details about what is possible on iOS without the new APIs for sure, but it seems like that is all stuff MCWS could handle now.  And, the difference in work seems only to be the seek to the bookmark (and a small API change to allow MCWS to issue a "set bookmark" command so that you could do it in that order - play on mobile, then stop, rather than stop, then load and play).

In any case, iTunes is adding it (and it is seamless like that), so I think it is worth looking at for sure.  That's a sick feature.

[glynor]

Of course these feature could additionally be implemented via Continuity as a one-button command via the lock screen if you have an all-Apple setup with JRemote and the Mac version of MC, but I'd rather things stay as open as possible.

You could do it with one button even through MCWS exclusively.

MCWS knows the playstate of the server.
And JRemote knows its own playstate (as does Gizmo).

One difference would be that the OSX and iOS APIs are smarter than just using a web service.  It works even if the Mac and the iOS device aren't connected to the same network (or any network at all), and it can detect proximity, so it only offers the option when you are close by to the devices in question.

That's nice, but I agree not a dealbreaker since the alternative would work on Windows and Gizmo.  (But, if available, and they could make use of both an internal system, and the API "proximity detection" type of effect, that would be extra sweet.)

[glynor]

I'd also be curious to see what other features this new stuff could give us.

JRemote can "play" any filetype that MC will serve us now, without having to implement specific reading functionality.  I want to open a PDF that MC knows about?  I can Send to > GoodReader now, without JRemote having to specifically implement Goodreader functionality.

That's awesome, and opens up a whole world of possibilities.

I also think the ability to have separate "extensions" to apps, opens a whole possibility of new categories of applications.  Third-party visualizers?  I hope, hope, hope Soundspectrum was watching.

[6233638]

JRemote can "play" any filetype that MC will serve us now, without having to implement specific reading functionality.  I want to open a PDF that MC knows about?  I can Send to > GoodReader now, without JRemote having to specifically implement Goodreader functionality.

I'm pretty sure that apps have already been able to register certain file types and show up in the Send to… menu since iOS 6 if not earlier.
My understanding is that what's new would be the ability to essentially load a GoodReader view inside JRemote as a plug-in, if both applications have support for this.
But doesn't iOS offer native PDF rendering anyway?

[glynor]

I'm pretty sure that apps have already been able to register certain file types and show up in the Send to… menu since iOS 6 if not earlier.
My understanding is that what's new would be the ability to essentially load a GoodReader view inside JRemote as a plug-in, if both applications have support for this.
But doesn't iOS offer native PDF rendering anyway?

No, those apps had to specifically code for GoodReader (or whatever). There were some URL tricks you could do, and a system share sheet control (recently) that you could use, but no framework or API to specifically enable it.  The sender app and the receiver app had to agree on the system.  And it created separate copies because each app had its own isolated filesystem (their sandbox).

They added essentially global open with capabilities, and shared storage space.

And they included extension support too, but the new share sheet changes are huge.

[glynor]

Actually, I was wrong.

Or we were both kinda right.  I had a feeling I was somewhat wrong above, even as I wrote it.  iOS 6 did add Share Sheets, you're right, and it was more than I was initially thinking.  However, they were/are limited in a number of ways.  One of the biggest changes is that they added shared storage (and a data exchange API), so the apps can now do it without creating their own copy of the document (which is obviously troublesome for a storage management perspective, and prevents you from using the same document with many different applications).  That is now solved.

And, now developers can introduce their own share sheet extensions, and the end user can re-order applications in the sharing menu (and hide those they don't use).

So, conceivably, you could display the PDF right in-line, with only the one copy (just using that as an example).

[6233638]

One of the biggest changes is that they added shared storage, so the apps can now do it without creating their own copy of the document (which is obviously troublesome for a storage management perspective, and prevents you from using the same document with many different applications).  That is now solved.

Yes, I've been saying since the beginning that iOS needed a shared document storage area to avoid the endless duplicate files that are created when you pass documents between apps. It's a huge addition.

So, conceivably, you could display the PDF right in-line, with only the one copy (just using that as an example).

Yes, as long as GoodReader or another app have the ability to render in a frame inside the JRemote app. (as I understood it)
And I know you just happened to pick PDF for your example, and it could be any other format that a certain app supports which JRemote does not, but again; doesn't iOS have native PDF support? (similar to the way you can create a web view inside your app)
It seems like you would be better integrating a basic PDF reader into JRemote than handling it externally.

[glynor]

Well, yeah... I was just picking PDF as an example, and perhaps it wasn't the best one since they do have native PDF rendering (you might need to use a UIWebView though, not sure).

But, generally, no.  I'd rather have it render "non-core" files in a tool suited for the task.  It is fine if they want to do a preview (which would be nice for things like liner notes), but I have hundreds of books in MC.  I don't think they're going to compare to the nice PDF readers I have on my iOS devices.

Especially since using the Sharing APIs is now so flexible, and reasonably easy.

[nitephlight]

ive been trying to avoid all the fanboy troll wars over the internet, but do you see any interesting advances over android's intent component system? from what it looks like, the Sharing API would not be a global system as it is implemented in android, rather a way for developers to bridge compliementary apps tightly together without the need for OS level regulation?