Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Quick Links
Categories
- 7.8K All Categories
- 11 Help with translations
- 4.2K General questions
- 107 Roadmap
- 358 Game & application design
- 316 Plugins
- 70 User experience
- 75 Marketplace
- 291 Code snippets
- 34 Building a team?
- 269 Suggestions & requests
- 352 Announce your apps made with Gideros.
- 90 Step by step tutorials
- 668 Bugs and issues
- 195 Introduce yourself
- 239 Announcements
- 106 Forum talk
- 404 Relax cafe
In this Discussion
IOS Image Picker Plugin
Folks,
I'm working on a game that needs access to the IOS photo library and camera so I've written a plugin to give easy access to these facilities. It's for IOS only and is available at:
http://dl.dropbox.com/u/2242074/Bowerhaus1.0.zip
The unzipped folder contains a number of support classes in addition to the image picker plugin and I've released them all under the MIT license (which basically means you can do what you like with them providing you keep the copyright notice and licence details in the files). I intend to add more tools and classes in future but the ones that are there now are required for running the image picker demo. See the README note for details.
To get started, copy the BhImagePicker.mm file from the folder of the same name into your player Plugins folder and rebuild. You may need to find "gideros.h" and add this to the Plugins folder too. Usage instructions are in the BhImagePickerDemo project. Basically you call one of:
bool pickImage(sourceType, callbackTarget, onPickerDismissedFunc, onImageReadyFunc)
or
bool pickImageIpad(sourceType, callbackTarget, onPickerDismissedFunc, onImageReadyFunc,
popoverWidth, popoverHeight, popoverOriginX, popoverOriginY)
If you don't need to specify the placement of the popover controller view on the iPad then you can just call the former function (on iPhone or iPad) to get a default placement. These functions will bring up a an iOS image picker. When this is dismissed:
callBackTarget:onPickerDismissedFunc(hasImage)
will be called back in your Lua code. If the pick was cancelled then (hasImage) will be false and that will be the end of it. Otherwise, if an image was chosen, (hasImage) will be true. At this point you can choose to resize the (potentially) large image before it is saved to a file. Also, you may choose to display a "wait" activity spinner here to inform the user while the file is being saved. Depending on the file size this may take several seconds. See the example project for full details.
Once your onPickerDismissedFunc() has returned, the plugin will continue by saving a temporary PNG file containing the picked (and possibly resized) image. You will be passed this file via another callback:
callbackTarget:onImageReadyFunc(imgFile)
You MUST do something with the file at this point. Either move it to a more permanent location or load it in as a texture. When your onImageReadyFunc() returns the file will be deleted! At this point, if you started an activity spinner you can dismiss it.
Now, I have to say that this is the first time I've written any Objective-C and it has been about a hundred years (!) since I've had to deal with memory management so you might like to check through the plugin code for retain/release errors. Please let me know if you find anything out of kilter. If you get any Lua errors in your callback functions you will likely crash the player or your app. I think this is a feature of Gideros although maybe there is a more defensive way to code the plugin?
I do have a few questions for @atilim at this point:
1) If you run the example program you will see that the memory display at the bottom continues to climb gradually when the app isn't doing anything. This gets cleared down when the code performs a collectgarbage() following a successful image pick. However, I would have thought that Gideros should be occasionally doing a GC anyway. Is this not the case?
2) Is my memory display (which is taken from a piece of your code I found on the forum) including memory that has been allocated as textures or do I need to add some debug in the plugin itself to monitor texture memory to make sure I don't have any leaks?
3) I tried to purchase an Indie license for Gideros today and got a PayPal error: "We cannot process this transaction because there is a problem with the PayPal email address supplied by the seller. Please contact the seller to resolve the problem."
I hope these tools are useful. Please let me know if you'd like any enhancements/bugs fixes made.
Best regards
Andy Bower
I'm working on a game that needs access to the IOS photo library and camera so I've written a plugin to give easy access to these facilities. It's for IOS only and is available at:
http://dl.dropbox.com/u/2242074/Bowerhaus1.0.zip
The unzipped folder contains a number of support classes in addition to the image picker plugin and I've released them all under the MIT license (which basically means you can do what you like with them providing you keep the copyright notice and licence details in the files). I intend to add more tools and classes in future but the ones that are there now are required for running the image picker demo. See the README note for details.
To get started, copy the BhImagePicker.mm file from the folder of the same name into your player Plugins folder and rebuild. You may need to find "gideros.h" and add this to the Plugins folder too. Usage instructions are in the BhImagePickerDemo project. Basically you call one of:
bool pickImage(sourceType, callbackTarget, onPickerDismissedFunc, onImageReadyFunc)
or
bool pickImageIpad(sourceType, callbackTarget, onPickerDismissedFunc, onImageReadyFunc,
popoverWidth, popoverHeight, popoverOriginX, popoverOriginY)
If you don't need to specify the placement of the popover controller view on the iPad then you can just call the former function (on iPhone or iPad) to get a default placement. These functions will bring up a an iOS image picker. When this is dismissed:
callBackTarget:onPickerDismissedFunc(hasImage)
will be called back in your Lua code. If the pick was cancelled then (hasImage) will be false and that will be the end of it. Otherwise, if an image was chosen, (hasImage) will be true. At this point you can choose to resize the (potentially) large image before it is saved to a file. Also, you may choose to display a "wait" activity spinner here to inform the user while the file is being saved. Depending on the file size this may take several seconds. See the example project for full details.
Once your onPickerDismissedFunc() has returned, the plugin will continue by saving a temporary PNG file containing the picked (and possibly resized) image. You will be passed this file via another callback:
callbackTarget:onImageReadyFunc(imgFile)
You MUST do something with the file at this point. Either move it to a more permanent location or load it in as a texture. When your onImageReadyFunc() returns the file will be deleted! At this point, if you started an activity spinner you can dismiss it.
Now, I have to say that this is the first time I've written any Objective-C and it has been about a hundred years (!) since I've had to deal with memory management so you might like to check through the plugin code for retain/release errors. Please let me know if you find anything out of kilter. If you get any Lua errors in your callback functions you will likely crash the player or your app. I think this is a feature of Gideros although maybe there is a more defensive way to code the plugin?
I do have a few questions for @atilim at this point:
1) If you run the example program you will see that the memory display at the bottom continues to climb gradually when the app isn't doing anything. This gets cleared down when the code performs a collectgarbage() following a successful image pick. However, I would have thought that Gideros should be occasionally doing a GC anyway. Is this not the case?
2) Is my memory display (which is taken from a piece of your code I found on the forum) including memory that has been allocated as textures or do I need to add some debug in the plugin itself to monitor texture memory to make sure I don't have any leaks?
3) I tried to purchase an Indie license for Gideros today and got a PayPal error: "We cannot process this transaction because there is a problem with the PayPal email address supplied by the seller. Please contact the seller to resolve the problem."
I hope these tools are useful. Please let me know if you'd like any enhancements/bugs fixes made.
Best regards
Andy Bower
Likes: gorkem, Zoyt, avo, ndoss, chipster123, atilim, Caroline, MikeHart, SatheeshJM
tweets: @ insidebowerhaus blog: http://bowerhaus.eu/blog/blog.html
+1 -1 (+9 / -0 )Share on Facebook
Comments
I actually had the same question as 2, is there anyway to display texture memory used?
@avo Currently, the used texture memory info is logged at Xcode's console or at Logcat. You can look at these locations while we're adding the function to get the used texture memory.
Likes: mehmetuysal
(but stackdump originates from the Lua manual pages, not me
https://deluxepixel.com
The original plugin has been superseded by a version written in Lua on top of the BhWax plugin. See:
http://bowerhaus.eu/blog/files/hot_wax.html
best regards
Likes: SinisterSoft
seems to me that some features like Accessing photos, camera, phone functions. All common to most tablets and phones.
Likes: phongtt
---------------------------------------
http://www.giderosmobile.com/forum/discussion/2319/jvbridge-plugin-android#Item_1
I'm guessing it wouldn't be too hard for someone to build an ImagePicker module using this bridge. It might even be possible to make it compatible with the IOS Wax version. I'm afraid Android isn't on my roadmap right now or I'd have looked at it myself (I'm alway open to financial incentives of course).
best regards