For your storePicture function it is better to run the MediaScanner to
add an image file to the MediaStore, see
http://developer.android.com/reference/android/media/MediaScannerConnection.html
Just create a MediaScannerConnection, provide a
MediaScannerConnectionClient, and scan the file. The
There is also a bug in PS mobile, and one more reason why you should
not assume anything about the resulting intent data. When you send a
PNG file for editing, PS returns a file with the PNG extension but it
is actually a JPEG.
On Mar 15, 4:54 pm, webmonkey webmonke...@gmail.com wrote:
For your
Thanks for the tip, my storePicture() function was based on some code that I
had read in the android camera app... and I wasn't really happy with it so I
will sure modify this soon.
Thanks again !
On Mon, Mar 15, 2010 at 4:54 PM, webmonkey webmonke...@gmail.com wrote:
For your storePicture
You can use Astro File Manager or Estrongs File Explorer to backup the
Photoshop app on your sdcard.
Then, transfer the apk on your computer and install it on a running
emulator using adb.
adb install Photoshop.apk
Now, I implemented a workaround for the problem I detected before:
Photoshop
can we test this feature in emulator
with regards
Nayana
On Fri, Mar 12, 2010 at 6:18 PM, Nivek kevin.gau...@gmail.com wrote:
They could have added the result to the MediaStore and returned that
uri... I'll have to do it myself or my edit button disappears after
editing a picture...
There is an inconsistency in their Uri handling... The app accepts
only content:// Uris but provides the result as a file:// Uri... so it
can't edit it's own result again without us having to work this
around...
They could have added the result to the MediaStore and returned that
uri... I'll have
They could have added the result to the MediaStore and returned that
uri... I'll have to do it myself or my edit button disappears after
editing a picture...
Actually, this is what I will have to do as a workaround, but I can't
see any reason why they shouldn't accept a file:// uri as an input
The document provided by Adobe does not mention how you should read
the returned Uri. For compatibility with future versions and other
image editors, you should not assume that it is a 'file:' scheme Uri,
it could also be a 'content:' scheme Uri. The ContentResolver will
handle it. here is the
ryan_f wrote:
@Frank Weiss - I do not believe so. I have not run any personal
tests, but I have not seen any data I have not put there either. Nor
have I compared file space to see if there's any missing. So I
believe the permissions are still set and therefore private files are
still
I have Photoshop.com 1.1.0 (build 3) installed on my T-Mobile G1,
Android 1.6 phone. When trying to use the described intent, no
application was found to handle it.
ActivityNotFoundException
No Activity found to handle Intent { act=android.intent.action.EDIT
dat =
ryan_f wrote:
I have Photoshop.com 1.1.0 (build 3) installed on my T-Mobile G1,
Android 1.6 phone. When trying to use the described intent, no
application was found to handle it.
ActivityNotFoundException
No Activity found to handle Intent { act=android.intent.action.EDIT
dat =
Try a 'content:' Uri instead of a 'file:' Uri.
On Mar 7, 9:38 am, ryan_f bluebaracu...@gmail.com wrote:
I have Photoshop.com 1.1.0 (build 3) installed on my T-Mobile G1,
Android 1.6 phone. When trying to use the described intent, no
application was found to handle it.
Try an actual image type (e.g., image/png) instead of image/*...
I started with this approach and it didn't work. However, see below.
Also, if aFile is not on the SD card, the Photoshop app may not have the
rights to access it.
aFile is most definitely on the SD card and the world has public
I agree that it should work on any (local) Uri, file: and content:
But i think they somehow need to tie it to the MediaStore content-
provider. And this makes sense, because content-providers are the main
mechanism with which data is shared amongst the applications.
This means, that if you have
But i think that the Photoshop.com intent is designed with the idea
that another app queries the *content-provider* for images (not the
file-system)
If your app is a file browser/manager and the user wants to open a
file to edit instead of view means you only have the file in which to
work.
Correct me if I'm wrong, but wouldn't an inter-activity file intent fail due
to Android's file system sandboxing model? If so, then you'll need to add a
provider to let the PS activity get the content.
On Sun, Mar 7, 2010 at 7:36 PM, ryan_f bluebaracu...@gmail.com wrote:
But i think that the
Correct me if I'm wrong, but wouldn't an inter-activity file intent fail due
to Android's file system sandboxing model?
For files that are private to the app, you would be correct. People
can remove the SD card from the phone and plug it into a laptop/
desktop and download a bunch of content
@ryan_f Thanks for the clarification. You taught me something new. Hope it
helps the OP.
One question: When you remove the SD card and read it externally, are all
Android app's data accessable? Sounds like a security hole.
On Sun, Mar 7, 2010 at 10:01 PM, ryan_f bluebaracu...@gmail.com wrote:
@Frank Weiss - I do not believe so. I have not run any personal
tests, but I have not seen any data I have not put there either. Nor
have I compared file space to see if there's any missing. So I
believe the permissions are still set and therefore private files are
still unreadable even
19 matches
Mail list logo
