Code and Control Reuse Across Desktop, Web, and iOS?

I really want to use the amazing CalendarTimeChooser that @Mike Cotrone put together on Web, but it was designed for Desktop. So, I thought, no biggie, I’ll just make a new Web Project, copy/paste everything over and fix stuff. The problem is that all the UI elements are all classed differently. Since a Window isn’t a WebPage, a Label isn’t a WebLabel, and the same for many other controls they can’t be pasted and then changed.

Are there any Xojo tools to make sharing code between Desktop, Web, and iOS? Any tools to pasting the objects which would convert them to the corresponding controls and show the methods, events, and properties that aren’t compatible?

Am I just wanting too much? When Xojo could only build for Desktop app, just about all your code worked anywhere, but now there is a ton of kick butt open source code that can be used for one project type but not for another. It’s really frustrating. Ultimately, I wish there was one single Project could build for Desktop, Web, and iOS. I get that the controls can’t do everything on each project type, but couldn’t all the generic properties be listed at the top of the inspector with the differences in Desktop, Web, and iOS be listed below?

despite the “cross platform” designator, there are some things that just cannot cross from one platform directly to another.

Even Apple made it difficult with ObjC and Swift. for iOS your controls are UIxxx but for OSX they are NSxxx so you have to write the “business logic” apart from the “GUI logic” in order to increase the “shareability”

Well, not impossible between Desktop and Web - just hard. I purchased Jeremie Leroy’s TreeView control a few months back and it works in both web and desktop. However, it’s really just two code paths for web and desktop with a common interface. I thought the TreeView source was pretty clever at the time but I haven’t had time to really dissect what he did.

I suspect that anything with iOS will be hard, if not impossible for the immediate future. I know the goal was to make it so a button was a button regardless of desktop, web, or iOS. I suspect this is several years away but who knows.

I wonder how hard it would be to edit the ‘.xojo_code’ text files from a ‘Xojo Project’ file to convert the controls between projects?

I just took the ‘RecurringCanvas.xojo_code’ from Mike’s Project in the ‘1_Cal-TIme Recurring Folder’ that looks like the following and changed ‘Inherits Canvas’ to ‘Inherits WebCanvas’ and moved the file to my Web Project and it appeared!

[code]#tag Class
Protected Class RecurringCanvas
Inherits Canvas
#tag Event
Function MouseDown(X As Integer, Y As Integer) As Boolean

	  Return True
	End Function
#tag EndEvent[/code]

Right now “universal” code is difficult. My latest Animation Kit and Authentication Kit projects are universal, but if you have certain requirements, it could be impossible.

For example, if you need regex… tough luck, it isn’t available on iOS. Need threads? You’ll need a wrapper class. Sockets? Don’t bother. Timers? Should be great, but the new Timer doesn’t fire action events in console apps. Databases? iOS has a different SQLite database class, so that’ll be difficult.

Then you also have to worry about converting between String and Text, MemoryBlock and Xojo.Core.MemoryBlock, Date and Xojo.Core.Date, etc.

So it is possible in certain sets of code. But it’s currently an uphill battle. I’d like to comment on R3, but I won’t. It’ll get better, but now is not a good time to try to write universal code.

Uh… yes it is… perhaps XOJO doesn’t support it in the current immature version of Xojo for iOS, but iOS itself has NSRegularExpression
Most of what you mentioned is due to (my opinion) XOJO’s need/desire to implement a new framework… but don’t blame missing functionaly on iOS, when in fact it is a matter of XOJO not yet implementing it without the use of declares

@Kem Tekinay and I put together RegEx classes in iOSKit for anyone needing them.

for the sake of interest, here is a routine I used in XOJO
and below is the same routine translated to SWIFT

FUNCTION isValidURL(s AS String) as Bool
    Dim rg As New RegEx
    Dim err_flag As Boolean
    If Trim(url)="" Then Return True
    err_flag=False
    rg.searchPattern="(?i)\\b(?:(?:https?|ftp):\\/\\/|www\\.)[-a-z0-9+&@#\\/%?=~_|!:,.;]*[-a-z0-9+&@#\\/%=~_|]"
    err_flag=(rg.search(url)= Nil)
    Return Not err_flag
    return true
END FUNCTION
func isValidURL(s:String) -> Bool {
    let searchFor:String="(?i)\\\\b(?:(?:https?|ftp):\\\\/\\\\/|www\\\\.)[-a-z0-9+&@#\\\\/%?=~_|!:,.;]*[-a-z0-9+&@#\\\\/%=~_|]"
    let regex = NSRegularExpression(pattern: searchFor, options: .CaseInsensitive, error: nil)
    let matches = regex!.matchesInString(s, options: nil, range: NSMakeRange(0, count(s))) as! Array<NSTextCheckingResult>
    if let match = matches.first { return true }
    return false
}

Jason… I don’t know it this might be of value to your RegEx classes or not
but I just discovered this
If all you want to do is insure a string matches a RegEx pattern Swift you don’t need all the I posted above it seems

func urlIsValid(s:String) -> Bool {
     let searchFor:String="(?i)\\\\b(?:(?:https?|ftp):\\\\/\\\\/|www\\\\.)[-a-z0-9+&@#\\\\/%?=~_|!:,.;]*[-a-z0-9+&@#\\\\/%=~_|]"
    return NSPredicate(format: "SELF MATCHES %@", searchFor).evaluateWithObject(s)
}

Um, sorry. I guess it wasn’t clear I was talking about the new Xojo framework on a Xojo forum in a thread about the new framework.

true, but you comment indicated it was not availalbe of iOS, not XOJO for iOS

and my comments are an attempt to provide information that may or may not help Jason make his declare libaray better to provide some level of functionality to Xojo for iOS

I’ll have to look into it “in the future”. When we created the Regex declares we tried to mirror the desktop classes as closely as possible so that if the classes are eventually implemented in the future the only difference in code would be the module name when using them. I have no doubt that there is an easier way to do it like you posted but that wasn’t the goal of what we were putting together.