[MonoTouch] MT.Dialog - Implementing a Tapped event
I've got a class that is deriving from the MT.Dialog element, it looks like
this
https://gist.github.com/3851206
I've copied the way *StringElement* works, with an override of the *Selected
* method to fire the *Tapped* event.
public override void Selected (DialogViewController dvc,
UITableView tableView, NSIndexPath indexPath)
{
// GR - this never gets invoked!
if (Tapped != null)
Tapped (this, EventArgs.Empty);
tableView.DeselectRow (indexPath, true);
}
Trouble is the *Selected *method is never getting invoked. I can't see the
difference between what I've got, and the way StringElement is working.
Any ideas what I'm missing here?
Thanks everyone!
--
*Phil *Cockfield
___
MonoTouch mailing list
MonoTouch@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/monotouch
[MonoTouch] Playing Media from iPod Library
I'm wanting to incorporate (playback) songs that user's have purchased on iTunes, that are in their iPod library on the device. Is this possible? Or does it somehow break an Apple restriction or DRM issue, does anyone know? -- *Phil *Cockfield ___ MonoTouch mailing list MonoTouch@lists.ximian.com http://lists.ximian.com/mailman/listinfo/monotouch
Re: [MonoTouch] Playing Media from iPod Library
Oh - that looks great. Seems like this is technically possible. Awesome. Cheers *Nic*. On Mon, Oct 8, 2012 at 10:31 PM, Nic Wise n...@fastchicken.co.nz wrote: You'll need to get dirty with some media player API's http://mobile.tutsplus.com/tutorials/iphone/ios-sdk-music-library-access/ look for: registerMediaPlayerNotifications Step 10: Showing the Media Picker That should help a bit :) Also: http://samples.xamarin.com/Details/iOS/2c1eba2d-8abc-408e-8ee8-a03ffac6ffde http://stackoverflow.com/questions/8589423/how-can-i-play-the-songs-from-ipod-library-in-iphone-app On Mon, Oct 8, 2012 at 9:06 AM, Phil Cockfield p...@cockfield.net wrote: I'm wanting to incorporate (playback) songs that user's have purchased on iTunes, that are in their iPod library on the device. Is this possible? Or does it somehow break an Apple restriction or DRM issue, does anyone know? -- *Phil *Cockfield ___ MonoTouch mailing list MonoTouch@lists.ximian.com http://lists.ximian.com/mailman/listinfo/monotouch -- Nic Wise t. +44 7788 592 806 | @fastchicken | http://www.linkedin.com/in/nicwise b. http://www.fastchicken.co.nz/ mobileAgent (for FreeAgent): get your accounts in your pocket. http://goo.gl/IuBU Trip Wallet: Keep track of your budget on the go: http://goo.gl/ePhKa Earnest: Self-employed? Track your business expenses and income. http://earnestapp.com Nearest Bus: find when the next bus is coming to your stop. http://goo.gl/Vcz1p London Bike App: Find the nearest Boris Bike, and get riding! http://goo.gl/Icp2 -- *Phil *Cockfield ___ MonoTouch mailing list MonoTouch@lists.ximian.com http://lists.ximian.com/mailman/listinfo/monotouch
[MonoTouch] MT.Dialog: RadioElements Weird When Added from Task/Thread
Here is an AppDelegate that contains an example of the problem I'm finding
with MT.Dialog and radio elements.
https://gist.github.com/3780834
This is just a *DialogViewController *that contains 3 *RadioElement*'s.
The problem is that when the radio-elements are added via a background
thread/task, which then marshals back onto the UI thread, the
radio-elements turn up in the table in a selected state (the tick is
visible) and they do no respond to tap events, or change state on tap.
// FAILS: Add some items on a background thread.
// All items will be selected, and won't recieve click events.
Task.Factory.StartNew(() = {
BeginInvokeOnMainThread(() = addRadios(3));
});
Can anyone see what is going on here. This seems to be related to calling
back in from the background thread to update the UI. Is there something
I'm missing in how to do this safely?
Thanks!
--
*Phil *Cockfield
___
MonoTouch mailing list
MonoTouch@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/monotouch
[MonoTouch] Console just got really verbose
In the latest release of (I'm guessing MonoDevelop) ... the console has suddenly started prepending each line with a long date-time and assembly identifier Eg: 2012-09-10 12:28:29.615 CoreUnitTests[52931:1607] [PASS] ShouldConvertTo_DateTime 2012-09-10 12:28:29.615 CoreUnitTests[52931:1607] [PASS] ShouldConvertTo_Decimal 2012-09-10 12:28:29.616 CoreUnitTests[52931:1607] [PASS] ShouldConvertTo_Double Used to just be: [PASS] ShouldConvertTo_DateTime [PASS] ShouldConvertTo_Decimal [PASS] ShouldConvertTo_Double Does anyone know if there is a switch somewhere to turn this prefix off? I can't seem to find it. -- *Phil *Cockfield ___ MonoTouch mailing list MonoTouch@lists.ximian.com http://lists.ximian.com/mailman/listinfo/monotouch
[MonoTouch] Launching my App from link in SMS
I'm wondering if it's possible to cause my app to be launched based on a link in a TXT/SMS message. It's possible to do the reverse of this, using the iPhone URL scheme, sms:1-408-555-1212 REFhttp://developer.apple.com/library/ios/featuredarticles/iPhoneURLScheme_Reference/iPhoneURLScheme_Reference.pdf: Apple URL Scheme Reference But I would like to do the opposite. Send a TXT notification, then have the app launch from there. -- *Phil *Cockfield ___ MonoTouch mailing list MonoTouch@lists.ximian.com http://lists.ximian.com/mailman/listinfo/monotouch
Re: [MonoTouch] Launching my App from link in SMS
Wow - it damn well does work! Thanks *Jason*. That is huge. The reason I asked this is I was just talking with someone in academia who'd noticed on multiple projects they'd been trialling that TXT/SMS was far more effective as a trigger than Push notifications. For some reason, TXT (in this person's experience at least) seems to be categorised differently in users minds - and it acted upon more readily than push notifications. On Thu, Sep 6, 2012 at 9:45 AM, Jason Awbrey ja...@awbrey.net wrote: should be easy enough to test - try sending yourself a text containing a url scheme for an app you have registered (like twitter://...) On Wed, Sep 5, 2012 at 4:42 PM, Phil Cockfield p...@cockfield.net wrote: I'm wondering if it's possible to cause my app to be launched based on a link in a TXT/SMS message. It's possible to do the reverse of this, using the iPhone URL scheme, sms:1-408-555-1212 REFhttp://developer.apple.com/library/ios/featuredarticles/iPhoneURLScheme_Reference/iPhoneURLScheme_Reference.pdf: Apple URL Scheme Reference But I would like to do the opposite. Send a TXT notification, then have the app launch from there. -- *Phil *Cockfield ___ MonoTouch mailing list MonoTouch@lists.ximian.com http://lists.ximian.com/mailman/listinfo/monotouch -- *Phil *Cockfield ___ MonoTouch mailing list MonoTouch@lists.ximian.com http://lists.ximian.com/mailman/listinfo/monotouch
Re: [MonoTouch] A recipe for a memory leak ???
Thanks for the insights *Nic*.
That's quite good - it means the plan I had is pretty much OK as it's not
breaking some magic GC-fu that I didn't know about. I am responsible for
freeing up reference to the object, and as soon as I do that, then
magically in the background GC will take care of things.
And listening to a Disposed event, in my scheme, was all about making sure
I new when to free up the resources.
Awesome
--
*Phil *Cockfield
On Tue, Aug 28, 2012 at 10:26 PM, Nic Wise n...@fastchicken.co.nz wrote:
My understanding, and I may be wrong (quite likely, actually):
Dispose is called when the object goes out of a using scope. That bit is
deterministic - if you do this:
using (var fff = new Foo())
{
}
Dispose is always called at the end of that block. Same if you set it to
null; HOWEVER the GC isn't deterministic, you don't know when it'll happen.
In MT, I think it's quite aggressive, so it may be quite quickly, but it
also may not be.
However, if you have:
var list = new ListFoo();
using (var foo = new Foo())
{
list.Add( foo );
}
At this point, the list has a reference to foo , but it's dispose has
been called. If it had resources, they have been free'ed, but it's NOT
going to be GC'ed, as the list has a reference.
And to my (non) surprise, the C# docs have a good para on it :)
http://msdn.microsoft.com/en-us/library/yh598w02.aspx
You can instantiate the resource object and then pass the variable to the
using statement, but this is not a best practice. In this case, the
object remains in scope after control leaves the using block even though
it will probably no longer have access to its unmanaged resources. In other
words, it will no longer be fully initialized. If you try to use the object
outside the using block, you risk causing an exception to be thrown. For
this reason, it is generally better to instantiate the object in the using
statement
and limit its scope to theusing block.
For one thing, I'd suggest you clear the event once you have called it -
save's having a reference to another class (which may not be GC'able)
keeping this one around. Or work out how to do a WeakReference event. Use
an Action maybe?
IDisposable has little to do with the GC - it's all about making sure
resources are cleaned up properly. Normally, it calls dispose then goes out
of scope, so the GC gets it, but if you keep a reference around, it'll not
get GC'ed, even tho it HAS been disposed of.
Does that make sense?
N
On Mon, Aug 27, 2012 at 9:56 PM, Phil Cockfield p...@cockfield.netwrote:
I have a scenario where in one region of the app I have a collection
managing models. In other places (ie, within Controllers) I have
manipulation and lifecycle management of those models. A controller may
dispose of a model.
It would be clean for the collection to be alerted via an event when a
model is disposed of, so I can do things like remove this disposed object
from the collection.
class Foo : NSObject
{
public event EventHandler Disposed;
protected override void Dispose(bool disposing)
{
base.Dispose(disposing);
if (disposing Disposed != null) {
// Alert listeners who might want to clean up state
// based on the disposal of this instance.
Disposed(this, new EventArgs());
}
}
}
*Question*: I'm wondering, is this a recipe for a memory leak?
If I have something listening to a *Disposed *event, and then at the
moment that object is disposed of, some other reference kicks off into
action using the object. Would that pull it out of the queue for the GC to
deal with?
Or once *Dispose* has been called, is the end inexorable?
I'm not doing any actual work with it - I'm just getting it out of my
collection and clean up associated state.
Thanks for any insights guys!
--
*Phil *Cockfield
___
MonoTouch mailing list
MonoTouch@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/monotouch
--
Nic Wise
t. +44 7788 592 806 | @fastchicken | http://www.linkedin.com/in/nicwise
b. http://www.fastchicken.co.nz/
mobileAgent (for FreeAgent): get your accounts in your pocket.
http://goo.gl/IuBU
Trip Wallet: Keep track of your budget on the go: http://goo.gl/ePhKa
Earnest: Self-employed? Track your business expenses and income.
http://earnestapp.com
Nearest Bus: find when the next bus is coming to your stop.
http://goo.gl/Vcz1p
London Bike App: Find the nearest Boris Bike, and get riding!
http://goo.gl/Icp2
___
MonoTouch mailing list
MonoTouch@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/monotouch
[MonoTouch] A recipe for a memory leak ???
I have a scenario where in one region of the app I have a collection
managing models. In other places (ie, within Controllers) I have
manipulation and lifecycle management of those models. A controller may
dispose of a model.
It would be clean for the collection to be alerted via an event when a
model is disposed of, so I can do things like remove this disposed object
from the collection.
class Foo : NSObject
{
public event EventHandler Disposed;
protected override void Dispose(bool disposing)
{
base.Dispose(disposing);
if (disposing Disposed != null) {
// Alert listeners who might want to clean up state
// based on the disposal of this instance.
Disposed(this, new EventArgs());
}
}
}
*Question*: I'm wondering, is this a recipe for a memory leak?
If I have something listening to a *Disposed *event, and then at the moment
that object is disposed of, some other reference kicks off into action
using the object. Would that pull it out of the queue for the GC to deal
with?
Or once *Dispose* has been called, is the end inexorable?
I'm not doing any actual work with it - I'm just getting it out of my
collection and clean up associated state.
Thanks for any insights guys!
--
*Phil *Cockfield
___
MonoTouch mailing list
MonoTouch@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/monotouch
[MonoTouch] PUT call to server using WebRequest
Hello! I'm using the *HttpWebRequest *to do a PUT on my server. The web-server is Node.js. The code is very by the book standard stuff: // Prepare the data. var dataText = data.ToString(); var byteArray = dataText.ToByteArray(); // Setup the web-request. var req = WebRequest.Create(url); req.Method = PUT; req.ContentType = Content-Type: application/json; charset=utf-8; req.ContentLength = byteArray.Length; // Process the stream. var dataStream = req.*GetRequestStream*(); dataStream.Write(byteArray, 0, byteArray.Length); dataStream.Close(); The problem is, when I call *GetRequestStream* it issues the request to the server and the response is complete before the next line (dataStream.Write) executes. As a result no data is actually sent. It's like the stream prematurely flushes upon creation. In fact, I didn't think it was supposed to call the server at all until *GetResponse* was invoked. Am I doing something dumb here? Or, is it something with the way Node is behaving (that would be weird if it were). Or is HttpWebRequest flakey? This works if I use *WebClient*. But I need HttpStatus codes - and my understanding is you can't get at those from *WebClient*. (If you can, I can't find them anywhere! :-)) Anyone else seeing weirdness with *HttpWebRequest*? -- *Phil *Cockfield ___ MonoTouch mailing list MonoTouch@lists.ximian.com http://lists.ximian.com/mailman/listinfo/monotouch
Re: [MonoTouch] PUT call to server using WebRequest
Ok. Good call - will revert to web client. Wired MS prioritized the HTTP status code so lowly I'm the API. I wonder if what I saw with HttpRequest is a bug. Probably not, because WebClient uses HttpRequest (I think), so perhaps some configuration setup I was getting wrong before opening the stream. Sent from my iPhone On 13/08/2012, at 2:30 AM, Jason Awbrey ja...@awbrey.net wrote: I believe you can get WebClient status codes by catching WebException and looking at it's Response.StatusCode assuming you're only interested in failure status codes, this might work for you On Sun, Aug 12, 2012 at 8:34 AM, Phil Cockfield p...@cockfield.net wrote: Hello! I'm using the HttpWebRequest to do a PUT on my server. The web-server is Node.js. The code is very by the book standard stuff: // Prepare the data. var dataText = data.ToString(); var byteArray = dataText.ToByteArray(); // Setup the web-request. var req = WebRequest.Create(url); req.Method = PUT; req.ContentType = Content-Type: application/json; charset=utf-8; req.ContentLength = byteArray.Length; // Process the stream. var dataStream = req.GetRequestStream(); dataStream.Write(byteArray, 0, byteArray.Length); dataStream.Close(); The problem is, when I call GetRequestStream it issues the request to the server and the response is complete before the next line (dataStream.Write) executes. As a result no data is actually sent. It's like the stream prematurely flushes upon creation. In fact, I didn't think it was supposed to call the server at all until GetResponse was invoked. Am I doing something dumb here? Or, is it something with the way Node is behaving (that would be weird if it were). Or is HttpWebRequest flakey? This works if I use WebClient. But I need HttpStatus codes - and my understanding is you can't get at those from WebClient. (If you can, I can't find them anywhere! :-)) Anyone else seeing weirdness with HttpWebRequest? -- Phil Cockfield ___ MonoTouch mailing list MonoTouch@lists.ximian.com http://lists.ximian.com/mailman/listinfo/monotouch ___ MonoTouch mailing list MonoTouch@lists.ximian.com http://lists.ximian.com/mailman/listinfo/monotouch
Re: [MonoTouch] Ensure Invoked on Main Thread (Performant???)
BTW for anyone following this thread, here's a simple (and I assume fast)
way to determine if you're on the main thread:
NSThread.Current.*IsMainThread*
*
*
This seems to report accurately whether it's on the main thread or not.
--
*Phil *Cockfield
On Wed, Aug 8, 2012 at 8:09 AM, Phil Cockfield p...@cockfield.net wrote:
Awesome - thanks *Rolf*.
On Tue, Aug 7, 2012 at 10:56 PM, Rolf Bjarne Kvinge r...@xamarin.comwrote:
Hi,
There are likely more efficient ways to this.
One way would be to have a [ThreadStatic] variable which you set to true
in your Main method. That way it'll only be true for the main thread.
The only way to really tell what is faster though is to actually measure
the difference (and do you actually know that this code is called a lot in
your app? If not, it won't be a problem. Have in mind that anything
UI-related will likely drown this piece of code completely).
Best regards,
Rolf
On Tue, Aug 7, 2012 at 12:43 PM, Phil Cockfield p...@cockfield.netwrote:
I've got some same code which is designed to make sure an Action is
invoked on the UI thread.
Here it is here:
https://gist.github.com/3284433
It uses this to determine if it's running on the UI thread. Is code the
most efficient way to do this? It seems a bit baroque to be marshalling
out over a *bool_objc_msgSend *type method.
private static bool IsMainThread()
{
return Messaging.bool_objc_msgSend(GetClassHandle(NSThread),
newSelector(
isMainThread).Handle);
}
Thanks!
--
*Phil *Cockfield
___
MonoTouch mailing list
MonoTouch@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/monotouch
--
*Phil *Cockfield
___
MonoTouch mailing list
MonoTouch@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/monotouch
Re: [MonoTouch] Ensure Invoked on Main Thread (Performant???)
Awesome - thanks *Rolf*.
On Tue, Aug 7, 2012 at 10:56 PM, Rolf Bjarne Kvinge r...@xamarin.comwrote:
Hi,
There are likely more efficient ways to this.
One way would be to have a [ThreadStatic] variable which you set to true
in your Main method. That way it'll only be true for the main thread.
The only way to really tell what is faster though is to actually measure
the difference (and do you actually know that this code is called a lot in
your app? If not, it won't be a problem. Have in mind that anything
UI-related will likely drown this piece of code completely).
Best regards,
Rolf
On Tue, Aug 7, 2012 at 12:43 PM, Phil Cockfield p...@cockfield.netwrote:
I've got some same code which is designed to make sure an Action is
invoked on the UI thread.
Here it is here:
https://gist.github.com/3284433
It uses this to determine if it's running on the UI thread. Is code the
most efficient way to do this? It seems a bit baroque to be marshalling
out over a *bool_objc_msgSend *type method.
private static bool IsMainThread()
{
return Messaging.bool_objc_msgSend(GetClassHandle(NSThread),
newSelector(
isMainThread).Handle);
}
Thanks!
--
*Phil *Cockfield
___
MonoTouch mailing list
MonoTouch@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/monotouch
--
*Phil *Cockfield
___
MonoTouch mailing list
MonoTouch@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/monotouch
Re: [MonoTouch] MT.Dialog: Selected Event while in Edit Mode
Cool. Thanks Nic. On Mon, Aug 6, 2012 at 9:50 PM, Nic Wise n...@fastchicken.co.nz wrote: I suspect it's a custom cell. I'm not 100% sure how they'd do it without custom-drawing everything (ie, not using a grouped tableview type), but it looks like a one-off :) If you have an image, you may need to EnableInteraction (or something similar) in order for it to receive taps. Same with UILabels. On Sun, Aug 5, 2012 at 9:01 PM, Phil Cockfield p...@cockfield.net wrote: Hey *Nic*, No, what I mean is when a *Contact* is in edit mode. If you put a Contact into Edit mode, then scroll down to the bottom you'll see (for example) the *( + ) add field* cell. Both the ( + ) icon AND the cell (add field) is tappable. Not so in MT.Dialog. The *selected* method is never getting called from the *DVC*. Any ideas? On Sun, Aug 5, 2012 at 11:08 PM, Nic Wise n...@fastchicken.co.nz wrote: I always thought the contact editing was 2 forms. You had one for display, and one for editing - rather than it being the editing mode of the same form. Could be wrong tho :) On Sun, Aug 5, 2012 at 10:36 AM, Phil Cockfield p...@cockfield.netwrote: In *MT.Dialog* I would like to react when a cell (Element) is selected WHILE the table is in edit mode. It appears that the DVC is never invoking the Selected method while in the edit state ( eg. TableView.*SetEditing*( true, true ); ) The reason I want to do this is to achieve the same effect as in the iOS Contacts app with + Add New Address or + Add Field (with the Plus/Insert icon visible). It will be confusing for the user to only hit the ( + ) icon, when the whole cell look like a hit target. Anyway to do this? Thanks! -- *Phil *Cockfield ___ MonoTouch mailing list MonoTouch@lists.ximian.com http://lists.ximian.com/mailman/listinfo/monotouch -- Nic Wise t. +44 7788 592 806 | @fastchicken | http://www.linkedin.com/in/nicwise b. http://www.fastchicken.co.nz/ mobileAgent (for FreeAgent): get your accounts in your pocket. http://goo.gl/IuBU Trip Wallet: Keep track of your budget on the go: http://goo.gl/ePhKa Earnest: Self-employed? Track your business expenses and income. http://earnestapp.com Nearest Bus: find when the next bus is coming to your stop. http://goo.gl/Vcz1p London Bike App: Find the nearest Boris Bike, and get riding! http://goo.gl/Icp2 -- *Phil *Cockfield -- Nic Wise t. +44 7788 592 806 | @fastchicken | http://www.linkedin.com/in/nicwise b. http://www.fastchicken.co.nz/ mobileAgent (for FreeAgent): get your accounts in your pocket. http://goo.gl/IuBU Trip Wallet: Keep track of your budget on the go: http://goo.gl/ePhKa Earnest: Self-employed? Track your business expenses and income. http://earnestapp.com Nearest Bus: find when the next bus is coming to your stop. http://goo.gl/Vcz1p London Bike App: Find the nearest Boris Bike, and get riding! http://goo.gl/Icp2 -- *Phil *Cockfield ___ MonoTouch mailing list MonoTouch@lists.ximian.com http://lists.ximian.com/mailman/listinfo/monotouch
[MonoTouch] MT.Dialog: Selected Event while in Edit Mode
In *MT.Dialog* I would like to react when a cell (Element) is selected WHILE the table is in edit mode. It appears that the DVC is never invoking the Selected method while in the edit state ( eg. TableView.*SetEditing*( true, true ); ) The reason I want to do this is to achieve the same effect as in the iOS Contacts app with + Add New Address or + Add Field (with the Plus/Insert icon visible). It will be confusing for the user to only hit the ( + ) icon, when the whole cell look like a hit target. Anyway to do this? Thanks! -- *Phil *Cockfield ___ MonoTouch mailing list MonoTouch@lists.ximian.com http://lists.ximian.com/mailman/listinfo/monotouch
Re: [MonoTouch] MT.Dialog: Selected Event while in Edit Mode
Hey *Nic*, No, what I mean is when a *Contact* is in edit mode. If you put a Contact into Edit mode, then scroll down to the bottom you'll see (for example) the *( + ) add field* cell. Both the ( + ) icon AND the cell (add field) is tappable. Not so in MT.Dialog. The *selected* method is never getting called from the *DVC*. Any ideas? On Sun, Aug 5, 2012 at 11:08 PM, Nic Wise n...@fastchicken.co.nz wrote: I always thought the contact editing was 2 forms. You had one for display, and one for editing - rather than it being the editing mode of the same form. Could be wrong tho :) On Sun, Aug 5, 2012 at 10:36 AM, Phil Cockfield p...@cockfield.netwrote: In *MT.Dialog* I would like to react when a cell (Element) is selected WHILE the table is in edit mode. It appears that the DVC is never invoking the Selected method while in the edit state ( eg. TableView.*SetEditing*( true, true ); ) The reason I want to do this is to achieve the same effect as in the iOS Contacts app with + Add New Address or + Add Field (with the Plus/Insert icon visible). It will be confusing for the user to only hit the ( + ) icon, when the whole cell look like a hit target. Anyway to do this? Thanks! -- *Phil *Cockfield ___ MonoTouch mailing list MonoTouch@lists.ximian.com http://lists.ximian.com/mailman/listinfo/monotouch -- Nic Wise t. +44 7788 592 806 | @fastchicken | http://www.linkedin.com/in/nicwise b. http://www.fastchicken.co.nz/ mobileAgent (for FreeAgent): get your accounts in your pocket. http://goo.gl/IuBU Trip Wallet: Keep track of your budget on the go: http://goo.gl/ePhKa Earnest: Self-employed? Track your business expenses and income. http://earnestapp.com Nearest Bus: find when the next bus is coming to your stop. http://goo.gl/Vcz1p London Bike App: Find the nearest Boris Bike, and get riding! http://goo.gl/Icp2 -- *Phil *Cockfield ___ MonoTouch mailing list MonoTouch@lists.ximian.com http://lists.ximian.com/mailman/listinfo/monotouch
[MonoTouch] INotifyPropertyChanged
In the past, I've always made a lot of use of property change notifications on Models. In .NET I've used the [*INotifyPropertyChanged*] interface and associated class from System.ComponentModel. Before I go blithely diving into adopting this pattern for iOS development - is this something other people do? Or in iOS is that discouraged. What are common ways for implementing property change observation patterns around models in this world. Thanks! -- *Phil *Cockfield ___ MonoTouch mailing list MonoTouch@lists.ximian.com http://lists.ximian.com/mailman/listinfo/monotouch
[MonoTouch] Glass Buttons
What is the class for the solid Glass like buttons that you see in the * UIActionSheet* (eg. OK, Cancel) and Delete in the iOS contacts app. They show as either Red, Green, or Black. I can't see any properties on *UIButton*, so figure they must be some other kind of button. Thanks! -- *Phil *Cockfield ___ MonoTouch mailing list MonoTouch@lists.ximian.com http://lists.ximian.com/mailman/listinfo/monotouch
Re: [MonoTouch] XIB file in sub-folder of Library Project
Awesome - thanks Jeff. On Fri, Jul 20, 2012 at 10:05 AM, Jeff Stedfast j...@xamarin.com wrote: Hi Phil, Never mind about submitting a bug report (I've just fixed it, so it should end up in the next release; 3.0.4 or 3.0.3.5 or whatever it ends up being). Jeff On Thu, Jul 19, 2012 at 4:46 PM, Jeff Stedfast j...@xamarin.com wrote: Hi Phil, This appears to be a bug in MonoDevelop's logic for calculating the .nib paths to be embedded into the resulting dll. Would you mind submitting a bug report about this to http://bugzilla.xamarin.com? I'll be taking a look into fixing this issue shortly. Thanks! Jeff On Wed, Jul 18, 2012 at 3:10 AM, Phil Cockfield p...@cockfield.netwrote: I have a *MonoTouch Library Project *referenced by my main MonoTouch iPhone app project. In that project I am creating an *iPhone View Controller* from the template which create the *UIViewController* along with the XIB file. I am creating this in a sub-folder of the library project (eg. * /my_lib/foo* ) This throws a build error, saying Error CS1566: Error reading resource file `/PATH/my_lib/obj/Debug/nibs/foo/bar.nib' (CS1566) This doesn't appear to be a limitation of library projects, because when I create a UIController/XIB template in the root folder it builds just find. Is there something special I need to configure so that it knows how to build the XIB file? Thanks -- *Phil *Cockfield ___ MonoTouch mailing list MonoTouch@lists.ximian.com http://lists.ximian.com/mailman/listinfo/monotouch -- *Phil *Cockfield ___ MonoTouch mailing list MonoTouch@lists.ximian.com http://lists.ximian.com/mailman/listinfo/monotouch
Re: [MonoTouch] Implementing Dispose on an [NSObject]
Thanks Rodrigo * * * * On Fri, Jul 20, 2012 at 8:40 AM, Rodrigo Kumpera kump...@xamarin.comwrote: You should only override void Dispose (bool disposing), and make sure to always call the base method. On Thu, Jul 19, 2012 at 5:15 PM, Phil Cockfield p...@cockfield.netwrote: What's the correct way of hooking into the *Dispose* invokation in classes derived from *NSObject*? I have an example in the gist here https://gist.github.com/3146438. https://gist.github.com/3146438 This is the full IDisposable pattern as I've seen it declared in the MSDN docs. There's a lighter weight version in the comment below. The problem is, NSObject implments IDisposable itself, and doesn't appear to provide any overridable *OnDisposing* type methods. I get a build warning saying to use the *new* keyword on my Dispose method. new is dangerous to use (right?). If the object is cast as NSObject, and Dispose is run - then the parent method will run, but my derived method won't. That's my understanding at least, please correct me if I'm wrong. So what is the best practice for hooking into dispose in these types of scenarios? Thanks! -- *Phil *Cockfield ___ MonoTouch mailing list MonoTouch@lists.ximian.com http://lists.ximian.com/mailman/listinfo/monotouch -- *Phil *Cockfield ___ MonoTouch mailing list MonoTouch@lists.ximian.com http://lists.ximian.com/mailman/listinfo/monotouch
[MonoTouch] Implementing Dispose on an [NSObject]
What's the correct way of hooking into the *Dispose* invokation in classes derived from *NSObject*? I have an example in the gist here https://gist.github.com/3146438. https://gist.github.com/3146438 This is the full IDisposable pattern as I've seen it declared in the MSDN docs. There's a lighter weight version in the comment below. The problem is, NSObject implments IDisposable itself, and doesn't appear to provide any overridable *OnDisposing* type methods. I get a build warning saying to use the *new* keyword on my Dispose method. new is dangerous to use (right?). If the object is cast as NSObject, and Dispose is run - then the parent method will run, but my derived method won't. That's my understanding at least, please correct me if I'm wrong. So what is the best practice for hooking into dispose in these types of scenarios? Thanks! -- *Phil *Cockfield ___ MonoTouch mailing list MonoTouch@lists.ximian.com http://lists.ximian.com/mailman/listinfo/monotouch
[MonoTouch] XIB file in sub-folder of Library Project
I have a *MonoTouch Library Project *referenced by my main MonoTouch iPhone app project. In that project I am creating an *iPhone View Controller* from the template which create the *UIViewController* along with the XIB file. I am creating this in a sub-folder of the library project (eg. */my_lib/foo*) This throws a build error, saying Error CS1566: Error reading resource file `/PATH/my_lib/obj/Debug/nibs/foo/bar.nib' (CS1566) This doesn't appear to be a limitation of library projects, because when I create a UIController/XIB template in the root folder it builds just find. Is there something special I need to configure so that it knows how to build the XIB file? Thanks -- *Phil *Cockfield ___ MonoTouch mailing list MonoTouch@lists.ximian.com http://lists.ximian.com/mailman/listinfo/monotouch
[MonoTouch] initWithNibName = Constructor ??
I'm working through some Obj-C examples, and translating them into MonoTouch. I'm looking at code which is within an *initWithNibName *method within a *UIViewController* Looking at Miguel's Rosetta Stone http://tirania.org/tmp/rosetta.htmlmapping index of Obj-C selectors to methods, I'm finding this: Class UIViewController Selector: *initWithNibName:bundle:* Method: *IntPtr Constructor ([NullAllowed] string nibName, [NullAllowed] NSBundle bundle);* Is it fair to say that is simply the C# constructor of my derived class? Or is that pointing at something else? -- *Phil *Cockfield ___ MonoTouch mailing list MonoTouch@lists.ximian.com http://lists.ximian.com/mailman/listinfo/monotouch
[MonoTouch] UIDatePicker - AM/PM : Getting it exactly the wrong way around.
I'm using a *UIDatePicker *control in a pretty standard way (I think).
That is, I'm not setting much configuration at all at initialization:
Control = new UIDatePicker(RectangleF.Empty){ AutoresizingMask =
UIViewAutoresizing.FlexibleWidth };
The problem is, when I read the selected *Date* value out of it, the AM/PM
values are exactly the wrong way around. Eg. 1PM is being returned as 1AM
and vice versa.
Here's a GIST of the entire code I've got (for context):
https://gist.github.com/3082372
Is this some kind of time-zone wierdness. I'm in NZ. Doesn't seem like
it's time-zones though, because it's an exact reversal of the AM/PM values,
not a shift in the time.
Thanks!
--
*Phil *Cockfield
___
MonoTouch mailing list
MonoTouch@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/monotouch
Re: [MonoTouch] OwnerDrawnElement vs. UIViewElement
Thanks *Nic*, So something like this(?): https://gist.github.com/3082446 If you're going of *Element*, you don't have a *UIView *to play with, right? I'm not sure if going all the way to Element is too low-level for me - but if I want complete rendering control, I think I need to. In the gist I have to create my own *TableViewCell*. Is this in the weeks, or the right way to do things? I suspect that this could be more efficient, given the warnings about cell's not being recycled when using the *UIViewElement.* From the docs: *UIViewElement *Can we used to host a standard UIView as an element, in this case no cell reuse will take place. On Tue, Jul 10, 2012 at 7:12 PM, Nic Wise n...@fastchicken.co.nz wrote: Yup, thats what I do: inherit off Element (or something a little further down the stack) and add my own stuff into the view yell for code. :) On Tue, Jul 10, 2012 at 6:31 AM, Phil Cockfield p...@cockfield.netwrote: I just found this by Miguel: http://stackoverflow.com/questions/4028356/monotouch-dialogs-ownerdrawnelement-highlight-not-working The OwnerDrawnElement was a contribution from the community, and it is not as sophisticated as it should be. I would not depend on it for anything beyond the trivially basic. I strongly recommend that you create your own Element, if you want to reuse some of the code for OwnerDrawElement, you could copy and paste that. So perhaps I should be just deriving from *Element* and overriding * GetCell*. Is that too low-level? What's the best practice here? Thanks! On Tue, Jul 10, 2012 at 2:27 PM, Phil Cockfield p...@cockfield.netwrote: When wanting to get in and totally control cell style rendering, is there a preferred approach between these two options: - OwnerDrawnElement - UIViewElement For [UIViewElement] the docs say : Can we used to host a standard UIView as an element, in this case no cell reuse will take place. That sounds bad. What I'm not experienced enough to know. What are people preferring to do when they want to render custom stuff? UIViewElement sounds easier. Is it like doing a bargain with the devil? Thanks. -- Phil Cockfield -- *Phil *Cockfield ___ MonoTouch mailing list MonoTouch@lists.ximian.com http://lists.ximian.com/mailman/listinfo/monotouch -- Nic Wise t. +44 7788 592 806 | @fastchicken | http://www.linkedin.com/in/nicwise b. http://www.fastchicken.co.nz/ Earnest: Self-employed? Track your business expenses and income. http://earnestapp.com Nearest Bus: find when the next bus is coming to your stop. http://goo.gl/Vcz1p mobileAgent (for FreeAgent): get your accounts in your pocket. http://goo.gl/IuBU Trip Wallet: Keep track of your budget on the go: http://goo.gl/ePhKa London Bike App: Find the nearest Boris Bike, and get riding! http://goo.gl/Icp2 -- *Phil *Cockfield ___ MonoTouch mailing list MonoTouch@lists.ximian.com http://lists.ximian.com/mailman/listinfo/monotouch
[MonoTouch] StringElement Button - As Stateful Button
I'm trying to something along the lines of the screen in the *Calendar* app
where you set the *Starts* and *Ends* times.
I have two *StringElement*'s that Im' using as the *Starts* and
*Ends*buttons, and when one or the other is selected I am showing a
UIDatePicker.
Root = new RootElement(Schedule){
new Section(){
(startElement = new StringElement(Starts)),
(endElement = new StringElement(Ends))
}
};
What I can't see how to do is to make either* startElement* or
*endElement*a stateful button. That is to say, when it is selected,
it retains it's
blue background, expressing that this is the value that is being edited by
the *DatePicker*.
Is this possible with* StringElement*? Equally, I can't see anything
obvious to do this on the *StyledStringElement*.
Thanks everyone.
--
*Phil *Cockfield
___
MonoTouch mailing list
MonoTouch@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/monotouch
Re: [MonoTouch] UIDatePicker - AM/PM : Getting it exactly the wrong way around.
Thanks Nic - good to know it actually is a TimeZone issue.
Being exactly 12 hours off made it look suspicious :)
There must be some other trick, beyond what Mikkel was showing with the *
ToLocalTime*() methods to have it convert correctly.
Mikkel suggested this:
picker.Date = date.ToLocalTime();
date = DateTime.SpecifyKind(picker.Date, DateTimeKind.Local).ToLocalTime();
Were there other time localization calls you were making for TripWallet?
On Wed, Jul 11, 2012 at 12:44 AM, Nic Wise n...@fastchicken.co.nz wrote:
The dates that come out of pickers are GMT. You are GMT+12 :)
(I had the same problem developing TripWallet - I was in NZ then, too)
On Tue, Jul 10, 2012 at 10:55 AM, Phil Cockfield p...@cockfield.net
wrote:
I'm using a UIDatePicker control in a pretty standard way (I think).
That
is, I'm not setting much configuration at all at initialization:
Control = new UIDatePicker(RectangleF.Empty){ AutoresizingMask =
UIViewAutoresizing.FlexibleWidth };
The problem is, when I read the selected Date value out of it, the AM/PM
values are exactly the wrong way around. Eg. 1PM is being returned as
1AM
and vice versa.
Here's a GIST of the entire code I've got (for context):
https://gist.github.com/3082372
Is this some kind of time-zone wierdness. I'm in NZ. Doesn't seem like
it's time-zones though, because it's an exact reversal of the AM/PM
values,
not a shift in the time.
Thanks!
--
Phil Cockfield
___
MonoTouch mailing list
MonoTouch@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/monotouch
--
Nic Wise
t. +44 7788 592 806 | @fastchicken | http://www.linkedin.com/in/nicwise
b. http://www.fastchicken.co.nz/
Earnest: Self-employed? Track your business expenses and income.
http://earnestapp.com
Nearest Bus: find when the next bus is coming to your stop.
http://goo.gl/Vcz1p
mobileAgent (for FreeAgent): get your accounts in your pocket.
http://goo.gl/IuBU
Trip Wallet: Keep track of your budget on the go: http://goo.gl/ePhKa
London Bike App: Find the nearest Boris Bike, and get riding!
http://goo.gl/Icp2
--
*Phil *Cockfield
___
MonoTouch mailing list
MonoTouch@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/monotouch
Re: [MonoTouch] OwnerDrawnElement vs. UIViewElement
Ah - cool. Thanks for the pointer to the recent sample! On Wed, Jul 11, 2012 at 12:43 AM, Nic Wise n...@fastchicken.co.nz wrote: That should work. I tend to make a normal cell and inject things into the ContentView, but I suspect yours is cleaner and the better way. My way dates back 12-24 months, so better tricks may have come up since then. The MWC app might be a good place to look: https://github.com/xamarin/mobile-samples/tree/master/MWC/MWC.iOS/UI/CustomElements .. as it's fairly recent. On Tue, Jul 10, 2012 at 11:08 AM, Phil Cockfield p...@cockfield.netwrote: Thanks *Nic*, So something like this(?): https://gist.github.com/3082446 If you're going of *Element*, you don't have a *UIView *to play with, right? I'm not sure if going all the way to Element is too low-level for me - but if I want complete rendering control, I think I need to. In the gist I have to create my own *TableViewCell*. Is this in the weeks, or the right way to do things? I suspect that this could be more efficient, given the warnings about cell's not being recycled when using the *UIViewElement.* From the docs: *UIViewElement * Can we used to host a standard UIView as an element, in this case no cell reuse will take place. On Tue, Jul 10, 2012 at 7:12 PM, Nic Wise n...@fastchicken.co.nz wrote: Yup, thats what I do: inherit off Element (or something a little further down the stack) and add my own stuff into the view yell for code. :) On Tue, Jul 10, 2012 at 6:31 AM, Phil Cockfield p...@cockfield.netwrote: I just found this by Miguel: http://stackoverflow.com/questions/4028356/monotouch-dialogs-ownerdrawnelement-highlight-not-working The OwnerDrawnElement was a contribution from the community, and it is not as sophisticated as it should be. I would not depend on it for anything beyond the trivially basic. I strongly recommend that you create your own Element, if you want to reuse some of the code for OwnerDrawElement, you could copy and paste that. So perhaps I should be just deriving from *Element* and overriding * GetCell*. Is that too low-level? What's the best practice here? Thanks! On Tue, Jul 10, 2012 at 2:27 PM, Phil Cockfield p...@cockfield.netwrote: When wanting to get in and totally control cell style rendering, is there a preferred approach between these two options: - OwnerDrawnElement - UIViewElement For [UIViewElement] the docs say : Can we used to host a standard UIView as an element, in this case no cell reuse will take place. That sounds bad. What I'm not experienced enough to know. What are people preferring to do when they want to render custom stuff? UIViewElement sounds easier. Is it like doing a bargain with the devil? Thanks. -- Phil Cockfield -- *Phil *Cockfield ___ MonoTouch mailing list MonoTouch@lists.ximian.com http://lists.ximian.com/mailman/listinfo/monotouch -- Nic Wise t. +44 7788 592 806 | @fastchicken | http://www.linkedin.com/in/nicwise b. http://www.fastchicken.co.nz/ Earnest: Self-employed? Track your business expenses and income. http://earnestapp.com Nearest Bus: find when the next bus is coming to your stop. http://goo.gl/Vcz1p mobileAgent (for FreeAgent): get your accounts in your pocket. http://goo.gl/IuBU Trip Wallet: Keep track of your budget on the go: http://goo.gl/ePhKa London Bike App: Find the nearest Boris Bike, and get riding! http://goo.gl/Icp2 -- *Phil *Cockfield -- Nic Wise t. +44 7788 592 806 | @fastchicken | http://www.linkedin.com/in/nicwise b. http://www.fastchicken.co.nz/ Earnest: Self-employed? Track your business expenses and income. http://earnestapp.com Nearest Bus: find when the next bus is coming to your stop. http://goo.gl/Vcz1p mobileAgent (for FreeAgent): get your accounts in your pocket. http://goo.gl/IuBU Trip Wallet: Keep track of your budget on the go: http://goo.gl/ePhKa London Bike App: Find the nearest Boris Bike, and get riding! http://goo.gl/Icp2 -- *Phil *Cockfield ___ MonoTouch mailing list MonoTouch@lists.ximian.com http://lists.ximian.com/mailman/listinfo/monotouch
[MonoTouch] MVC philosophy when it comes to deriving from [Element]
As I start to create custom cells by deriving from *Element* I need to be careful I don't start messing up the clean MVC separation works in iOS. Is this a true and fair way to think of things: - A derived [*Element*] should contain behavioral methods that are responsible only for on screen manipulation of the visuals of the Element's parts. It is conceptually the View of MVC. - A model per se should never be directly passed into a derived [* Element*], rather - The relationship between a model, and the way the Element displays is (via it's behavioral method mentioned above) should ALWAYS be managed through a *UIViewController* (or *DialogViewController* as the case may be). That seems clear, and logical to me at the moment. Is it this clear cut and simple - or do you guys start to blur things (passing models into Elements)...and if so, is that OK/recommended? It's tempting to just ram some controller-like model binding behavior into the derived element. Is that evil? Thanks! -- *Phil *Cockfield ___ MonoTouch mailing list MonoTouch@lists.ximian.com http://lists.ximian.com/mailman/listinfo/monotouch
Re: [MonoTouch] MVC philosophy when it comes to deriving from [Element]
But now I think this through further - saying an *Element* is just a view and it needs to have a Controller along side it doesn't totally work because you can't insert a controller into a *Section.* And you may want to encapsulate facets of behavioral-to-model logic within an Element, or Section so as not to have the root Controller become wildly complex being responsible for to many different things. These really are different kinds of things, right? Perhaps akin to a *View-Model *(??) Please humor this line of questioning. Backing out of a factoring and code-organization based on a faulty understanding of how to structure things gets more and more of a PITA with every new Element I make and use! :) Thanks guys!!! On Wed, Jul 11, 2012 at 7:41 AM, Phil Cockfield p...@cockfield.net wrote: As I start to create custom cells by deriving from *Element* I need to be careful I don't start messing up the clean MVC separation works in iOS. Is this a true and fair way to think of things: - A derived [*Element*] should contain behavioral methods that are responsible only for on screen manipulation of the visuals of the Element's parts. It is conceptually the View of MVC. - A model per se should never be directly passed into a derived [* Element*], rather - The relationship between a model, and the way the Element displays is (via it's behavioral method mentioned above) should ALWAYS be managed through a *UIViewController* (or *DialogViewController* as the case may be). That seems clear, and logical to me at the moment. Is it this clear cut and simple - or do you guys start to blur things (passing models into Elements)...and if so, is that OK/recommended? It's tempting to just ram some controller-like model binding behavior into the derived element. Is that evil? Thanks! -- *Phil *Cockfield ___ MonoTouch mailing list MonoTouch@lists.ximian.com http://lists.ximian.com/mailman/listinfo/monotouch
[MonoTouch] OwnerDrawnElement vs. UIViewElement
When wanting to get in and totally control cell style rendering, is there a preferred approach between these two options: - OwnerDrawnElement - UIViewElement For [UIViewElement] the docs say : Can we used to host a standard UIView as an element, in this case no cell reuse will take place. That sounds bad. What I'm not experienced enough to know. What are people preferring to do when they want to render custom stuff? UIViewElement sounds easier. Is it like doing a bargain with the devil? Thanks. -- Phil Cockfield ___ MonoTouch mailing list MonoTouch@lists.ximian.com http://lists.ximian.com/mailman/listinfo/monotouch
Re: [MonoTouch] OwnerDrawnElement vs. UIViewElement
I just found this by Miguel: http://stackoverflow.com/questions/4028356/monotouch-dialogs-ownerdrawnelement-highlight-not-working The OwnerDrawnElement was a contribution from the community, and it is not as sophisticated as it should be. I would not depend on it for anything beyond the trivially basic. I strongly recommend that you create your own Element, if you want to reuse some of the code for OwnerDrawElement, you could copy and paste that. So perhaps I should be just deriving from *Element* and overriding *GetCell*. Is that too low-level? What's the best practice here? Thanks! On Tue, Jul 10, 2012 at 2:27 PM, Phil Cockfield p...@cockfield.net wrote: When wanting to get in and totally control cell style rendering, is there a preferred approach between these two options: - OwnerDrawnElement - UIViewElement For [UIViewElement] the docs say : Can we used to host a standard UIView as an element, in this case no cell reuse will take place. That sounds bad. What I'm not experienced enough to know. What are people preferring to do when they want to render custom stuff? UIViewElement sounds easier. Is it like doing a bargain with the devil? Thanks. -- Phil Cockfield -- *Phil *Cockfield ___ MonoTouch mailing list MonoTouch@lists.ximian.com http://lists.ximian.com/mailman/listinfo/monotouch
[MonoTouch] Recording Sound
*[I apologize if this got posted twice. Posted it yesterday, but it didn't show up in the group]* I'm working with the *Sound* sample app: https://github.com/xamarin/monotouch-samples/blob/master/Sound/Sound/SoundViewController.cs It works for the first recording, but all subsequent recordings don't record. Or more specifically, I'm finding that on the Stop Recording on the 2nd..n recording the *recorder.finished* callback never gets invoked (see *line 55*). Is this a bug in the demo. Is there something about recorders that they perhaps need to be more fully disposed of or something. I'm loving that there is so little code needed to do this kind of thing. Thanks guys! -- *Phil *Cockfield ___ MonoTouch mailing list MonoTouch@lists.ximian.com http://lists.ximian.com/mailman/listinfo/monotouch
[MonoTouch] Recording Sound
[I apologize if this got posted twice. Posted it yesterday, but it didn't show up in the group] I'm working with the Sound sample app: https://github.com/xamarin/monotouch-samples/blob/master/Sound/Sound/SoundViewController.cs It works for the first recording, but all subsequent recordings don't record. Or more specifically, I'm finding that on the Stop Recording on the 2nd..n recording the recorder.finished callback never gets invoked (see line 55). Is this a bug in the demo. Is there something about recorders that they perhaps need to be more fully disposed of or something. I'm loving that there is so little code needed to do this kind of thing. Thanks guys! -- Phil Cockfield -- Phil Cockfield ___ MonoTouch mailing list MonoTouch@lists.ximian.com http://lists.ximian.com/mailman/listinfo/monotouch
[MonoTouch] Recording Sound
I'm working with the *Sound* sample app: https://github.com/xamarin/monotouch-samples/blob/master/Sound/Sound/SoundViewController.cs It works for the first recording, but all subsequent recordings don't record. Or more specifically, I'm finding that on the Stop Recording on the 2nd..n recording the *recorder.finished* callback never gets invoked (see *line 55*). Is this a bug in the demo. Is there something about recorders that they perhaps need to be more fully disposed of or something. I'm loving that there is so little code needed to do this kind of thing. Thanks guys! -- *Phil *Cockfield ___ MonoTouch mailing list MonoTouch@lists.ximian.com http://lists.ximian.com/mailman/listinfo/monotouch
Re: [MonoTouch] Side Navigation (a la Path and Facebook)
That is awesome *Nic*!
Thank you very much. Both that sample repo by James, and your
extrapolation of the concept in sample code is a brilliant start for me.
Also - want to say it again - your
webcasthttp://blog.xamarin.com/2012/07/02/styling-your-ios-apps-seminar/the
other day was hugely helpful. A really really really great
presentation.
--
*Phil *Cockfield
On Wed, Jul 4, 2012 at 6:57 AM, Nic Wise n...@fastchicken.co.nz wrote:
James Clancey has done a basic version of it:
https://github.com/Clancey/FlyOutNavigation
I've not seen anything else, tho. But on the surface, it shouldn't be too
hard. Two views, one under the other. Trigger something (button) and
animate the top view away. Trigger something (gesture?) and animate it back
in.
I did a basic one, with a huge UIImageView as the background, and you hit
something, and it just scrolled over the show the left side.
so, assuming you have a 320x2 x 480 image (non-retina) as the background
view (BaseView), the button (trigger) just calls SetInitialPage(0, true)
for the left side, and 0,true for the right side.
BaseView = new UIView(new RectangleF(new PointF(0,0),
Resources.Background.Size)); //Resources.Background is the big
image!baseView.BackgroundColor = Resources.MoleskineBackgroundColor; //it's a
color, but it's a patternView.AddSubview(baseView);
//just add it into the View's view... this is all just in a
UIViewController
public void TogglePage(){page = (page == 1) ? 0 : 1;
SetInitialPage(page);sideButton.SetTitle((page == 1) ?
: , UIControlState.Normal);}public override void
SetInitialPage(int page, bool animate = true){if
(animate){UIView.BeginAnimations(pagescroll);
UIView.SetAnimationDuration(0.75f);
UIView.SetAnimationCurve(UIViewAnimationCurve.EaseInOut);}
if (page == 0){ var baseViewBounds =
BaseView.Bounds;baseViewBounds.X = 0;
BaseView.Bounds = baseViewBounds;} else {var
baseViewBounds = BaseView.Bounds;baseViewBounds.X =
BaseView.Bounds.Width - 320;BaseView.Bounds = baseViewBounds;
}if (animate){
UIView.CommitAnimations();}base.SetInitialPage(page,
animate);}
On Wed, Jul 4, 2012 at 2:38 PM, Phil Cockfield p...@cockfield.net wrote:
I'm trying to do something akin to the emerging UI pattern of side
navigation that you see in apps like *Facebook* and *Path*.
This is where the root navigation options are shown via a bezel swipe
from the left, which peels the main app view mostly off screen, leaving a
hint of it still showing (say a 44px strip), with the navigation options
presenting themselves as having been sitting under the screen.
This pattern is detailed here:
http://www.androiduipatterns.com/2012/06/emerging-ui-pattern-side-navigation.html
How would I go about achieving something like this in MonoTouch? It
seems like a significant variant from from the *UINavigationController*does.
Thanks!
--
*Phil *Cockfield
___
MonoTouch mailing list
MonoTouch@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/monotouch
--
Nic Wise
t. +44 7788 592 806 | @fastchicken | http://www.linkedin.com/in/nicwise
b. http://www.fastchicken.co.nz/
Earnest: Self-employed? Track your business expenses and income.
http://earnestapp.com
Nearest Bus: find when the next bus is coming to your stop.
http://goo.gl/Vcz1p
mobileAgent (for FreeAgent): get your accounts in your pocket.
http://goo.gl/IuBU
Trip Wallet: Keep track of your budget on the go: http://goo.gl/ePhKa
London Bike App: Find the nearest Boris Bike, and get riding!
http://goo.gl/Icp2
___
MonoTouch mailing list
MonoTouch@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/monotouch
Re: [MonoTouch] Side Navigation (a la Path and Facebook)
BTW - what is that color:
baseView.BackgroundColor = Resources.*MoleskineBackgroundColor*;
//it's a color, but it's a pattern
Is that actually *UIImage* just named as color - or some other trick?
On Wed, Jul 4, 2012 at 12:37 PM, Phil Cockfield p...@cockfield.net wrote:
That is awesome *Nic*!
Thank you very much. Both that sample repo by James, and your
extrapolation of the concept in sample code is a brilliant start for me.
Also - want to say it again - your
webcasthttp://blog.xamarin.com/2012/07/02/styling-your-ios-apps-seminar/the
other day was hugely helpful. A really really really great
presentation.
--
*Phil *Cockfield
On Wed, Jul 4, 2012 at 6:57 AM, Nic Wise n...@fastchicken.co.nz wrote:
James Clancey has done a basic version of it:
https://github.com/Clancey/FlyOutNavigation
I've not seen anything else, tho. But on the surface, it shouldn't be too
hard. Two views, one under the other. Trigger something (button) and
animate the top view away. Trigger something (gesture?) and animate it back
in.
I did a basic one, with a huge UIImageView as the background, and you hit
something, and it just scrolled over the show the left side.
so, assuming you have a 320x2 x 480 image (non-retina) as the background
view (BaseView), the button (trigger) just calls SetInitialPage(0, true)
for the left side, and 0,true for the right side.
BaseView = new UIView(new RectangleF(new PointF(0,0),
Resources.Background.Size)); //Resources.Background is the big
image!baseView.BackgroundColor = Resources.MoleskineBackgroundColor; //it's
a color, but it's a patternView.AddSubview(baseView);
//just add it into the View's view... this is all just in a
UIViewController
public void TogglePage(){page = (page == 1) ? 0 : 1;
SetInitialPage(page);sideButton.SetTitle((page == 1) ?
: , UIControlState.Normal);}public override void
SetInitialPage(int page, bool animate = true){if
(animate){UIView.BeginAnimations(pagescroll);
UIView.SetAnimationDuration(0.75f);
UIView.SetAnimationCurve(UIViewAnimationCurve.EaseInOut);}
if (page == 0){ var baseViewBounds =
BaseView.Bounds;baseViewBounds.X = 0;
BaseView.Bounds = baseViewBounds;} else {var
baseViewBounds = BaseView.Bounds;baseViewBounds.X =
BaseView.Bounds.Width - 320;BaseView.Bounds =
baseViewBounds;}if (animate){
UIView.CommitAnimations();}
base.SetInitialPage(page, animate);}
On Wed, Jul 4, 2012 at 2:38 PM, Phil Cockfield p...@cockfield.netwrote:
I'm trying to do something akin to the emerging UI pattern of side
navigation that you see in apps like *Facebook* and *Path*.
This is where the root navigation options are shown via a bezel swipe
from the left, which peels the main app view mostly off screen, leaving a
hint of it still showing (say a 44px strip), with the navigation options
presenting themselves as having been sitting under the screen.
This pattern is detailed here:
http://www.androiduipatterns.com/2012/06/emerging-ui-pattern-side-navigation.html
How would I go about achieving something like this in MonoTouch? It
seems like a significant variant from from the *UINavigationController*does.
Thanks!
--
*Phil *Cockfield
___
MonoTouch mailing list
MonoTouch@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/monotouch
--
Nic Wise
t. +44 7788 592 806 | @fastchicken | http://www.linkedin.com/in/nicwise
b. http://www.fastchicken.co.nz/
Earnest: Self-employed? Track your business expenses and income.
http://earnestapp.com
Nearest Bus: find when the next bus is coming to your stop.
http://goo.gl/Vcz1p
mobileAgent (for FreeAgent): get your accounts in your pocket.
http://goo.gl/IuBU
Trip Wallet: Keep track of your budget on the go: http://goo.gl/ePhKa
London Bike App: Find the nearest Boris Bike, and get riding!
http://goo.gl/Icp2
--
*Phil *Cockfield
___
MonoTouch mailing list
MonoTouch@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/monotouch
Re: [MonoTouch] UIImage.FromFile and @2x images
Yeah - it's working for me too. I was initially thrown off by all the documentation saying it didn't - coupled with me being a dunce on including the files correctly as content in the product folder. But it works fine now with *FromFile*. Very convenient. On Thu, Jul 5, 2012 at 4:39 AM, Robert Reck rr...@keylogic.com wrote: All the documentation states they FromFile does not automatically apply the @2x. So unless there's a bug, you should be getting the non-retina images. Bob -- Sent from my iPhone On Jul 5, 2012, at 7:37 AM, Nic Wise n...@fastchicken.co.nz wrote: It doesn't? I use FromFile everywhere. Always appears to use the @2x version I suspect I need to double check my code :) On Thu, Jul 5, 2012 at 12:26 PM, Robert Jordan robe...@gmx.net wrote: On 05.07.2012 09:45, Mikkel Lønow wrote: Hi, FromFile should automatically apply the @2x suffix. Unlike FromBundle, FromFile does not apply the suffix. Robert ___ MonoTouch mailing list MonoTouch@lists.ximian.com http://lists.ximian.com/mailman/listinfo/monotouch -- Nic Wise t. +44 7788 592 806 | @fastchicken | http://www.linkedin.com/in/nicwise b. http://www.fastchicken.co.nz/ Earnest: Self-employed? Track your business expenses and income. http://earnestapp.com Nearest Bus: find when the next bus is coming to your stop. http://goo.gl/Vcz1p mobileAgent (for FreeAgent): get your accounts in your pocket. http://goo.gl/IuBU Trip Wallet: Keep track of your budget on the go: http://goo.gl/ePhKa London Bike App: Find the nearest Boris Bike, and get riding! http://goo.gl/Icp2 ___ MonoTouch mailing list MonoTouch@lists.ximian.com http://lists.ximian.com/mailman/listinfo/monotouch ___ MonoTouch mailing list MonoTouch@lists.ximian.com http://lists.ximian.com/mailman/listinfo/monotouch -- *Phil *Cockfield ___ MonoTouch mailing list MonoTouch@lists.ximian.com http://lists.ximian.com/mailman/listinfo/monotouch
[MonoTouch] Bundle Version not incrementing for TestFlight deployment
I'm incrementing my build version like this:
- In project:
Options General Main Settings *[X] Get version from parent
solution.*
- In solution:
Options General Main Settings Version { Set the version number -
eg. *0.1.2 *}
The problem is that when I deploy to TestFlight using the:
- Project *Deploy to Test Flight*
[with the Debug | iPhone build target selected]
The test flight output reports the deployed bundle as being 1.0:
Uploading to TestFlight...
Upload succeeded
Bundle version: 1.0
Install url:
https://testflightapp.com/install/7feee0fdf2c0397cec6e0fe0e29f35fe-MTg1OTI1OA/
Config url: https://testflightapp.com/dashboard/builds/complete/1859258/
Created at: 2012-07-05 01:00:42
Device family: iPhone
Notify: True
Team: MyTeam
Minimum os version: 5.1
Release notes: Stuff
Binary size: 4060357
Application was successfully published to TestFlight
And the result is that nothing new is added to my builds page on TestFlight
(because 1.0 is already there) and testers are not alerted of any new
build to install.
I can't see a version number on the *MonoTouch TestFlight Deployment* UI,
so is there some other way of incrementing the build number? Thanks!
--
*Phil *Cockfield
___
MonoTouch mailing list
MonoTouch@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/monotouch
Re: [MonoTouch] Bundle Version not incrementing for TestFlight deployment
Ah sweet! There it is. Thanks a lot *Bob*.
On Thu, Jul 5, 2012 at 6:14 PM, Robert Reck rr...@keylogic.com wrote:
The app version is set under the app build options. Right click on your
project (not the solution) and then click on app build options (I forget
the actual name of the section) and set the version there. It's currently
set to 1.0.
Bob
--
Sent from my iPhone
On Jul 5, 2012, at 8:55 PM, Phil Cockfield p...@cockfield.netmailto:
p...@cockfield.net wrote:
I'm incrementing my build version like this:
* In project:
Options General Main Settings [X] Get version from parent solution.
* In solution:
Options General Main Settings Version { Set the version number -
eg. 0.1.2 }
The problem is that when I deploy to TestFlight using the:
* Project Deploy to Test Flight
[with the Debug | iPhone build target selected]
The test flight output reports the deployed bundle as being 1.0:
Uploading to TestFlight...
Upload succeeded
Bundle version: 1.0
Install url:
https://testflightapp.com/install/7feee0fdf2c0397cec6e0fe0e29f35fe-MTg1OTI1OA/
Config url:
https://testflightapp.com/dashboard/builds/complete/1859258/
Created at: 2012-07-05 01:00:42
Device family: iPhone
Notify: True
Team: MyTeam
Minimum os version: 5.1
Release notes: Stuff
Binary size: 4060357
Application was successfully published to TestFlight
And the result is that nothing new is added to my builds page on
TestFlight (because 1.0 is already there) and testers are not alerted of
any new build to install.
I can't see a version number on the MonoTouch TestFlight Deployment UI, so
is there some other way of incrementing the build number? Thanks!
--
Phil Cockfield
[http://www.gravatar.com/avatar/99d0b4f26c68a563507c9e5a3d724126.png?s=50]
___
MonoTouch mailing list
MonoTouch@lists.ximian.commailto:MonoTouch@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/monotouch
--
*Phil *Cockfield
___
MonoTouch mailing list
MonoTouch@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/monotouch
[MonoTouch] Side Navigation (a la Path and Facebook)
I'm trying to do something akin to the emerging UI pattern of side navigation that you see in apps like *Facebook* and *Path*. This is where the root navigation options are shown via a bezel swipe from the left, which peels the main app view mostly off screen, leaving a hint of it still showing (say a 44px strip), with the navigation options presenting themselves as having been sitting under the screen. This pattern is detailed here: http://www.androiduipatterns.com/2012/06/emerging-ui-pattern-side-navigation.html How would I go about achieving something like this in MonoTouch? It seems like a significant variant from from the *UINavigationController* does. Thanks! -- *Phil *Cockfield ___ MonoTouch mailing list MonoTouch@lists.ximian.com http://lists.ximian.com/mailman/listinfo/monotouch
[MonoTouch] UIImage.FromFile and @2x images
What's the strategy for loading retina images via the *UIImage.FromFile*method? The documentation leads me to believe that only *FromBundle* does the automatic @2x file suffix checking - (however even with thatI can't actually see the retina versions loading). Anyhow - with *FromFile*, what I'm doing is checking whether the device has a retina screen, and if so I'm appending the @2x onto the path. *My problem is*: With the appended @2x path, FromFile return *null* - even when the file exists. Question: - Is the system rejecting the path with @2x in it perhaps? - Is there some other way I'm supposed to pull the retina images, or pathsperhaps automatically. Thanks! -- *Phil *Cockfield ___ MonoTouch mailing list MonoTouch@lists.ximian.com http://lists.ximian.com/mailman/listinfo/monotouch
