You have an application at App Store ? Did you used Declare in it ?

Emile_Schwarz · November 29, 2013, 10:06am

Just a stupid question * that arise to me when I awoke this morning:

There are a lot of people usig Xojo or Real Studio and that sold their application(s) with the App Store.

Is there people who do not use Declare in these application(s) ?

Some of them are the better ;-

Michel_Bujardet · November 29, 2013, 3:03pm

[quote=49742:@Emile Schwarz]Just a stupid question * that arise to me when I awoke this morning:

There are a lot of people usig Xojo or Real Studio and that sold their application(s) with the App Store.

Is there people who do not use Declare in these application(s) ?[/quote]

Some I use Declare some I don’t. Same difference

DaveS · November 29, 2013, 3:45pm

Using or not using a Declare does not affect “how good” an application is… nor is it relative to it being accepted or not accepted to the App Store.

It totally depends on what function the program needs to perform internally to provide the look/feel and function to the user.

jim_mckay · November 29, 2013, 6:19pm

Could be an issue if you use declares to depricated or private API’s.

Sam_Rowlands · November 30, 2013, 4:29am

Indeed, Private APIs will get a rejection. How can you tell?

#1 Search the Apple documentation: While it’s not 100% correct, if the API doesn’t exist in Apple’s docs, it’s either private, depreciated or simply undocumented. You can always ask here or on ADF to verify.

The only private APIs, I’ve come across are ones to do with Window transition animation (such as flipping the window).

#2 When you submit your application to the App Store, it auto checks against private APIs now, and so I would assume that Apple will reject it during the submission stage.

Sam_Rowlands · November 30, 2013, 4:30am

Other than that, all our apps on the App Store are using declares.

Emile_Schwarz · November 30, 2013, 9:42am

All: thank you for your answers.

I do not wanted to explain why I had in mind when asking the question (Star Trek prime directive).

What I had in mind was:
are-you using Xojo as a skeleton and write your application(s) with declare where these are needed (Xojo have nothing to achieve what you want to do / have bug / is slow / whatever) ?
you are using Xojo as is (no Declare / no external plug-in / pure Xojo) ?

I usually fall into traps everytime I start a new projects. These traps are either a hole in Xojo / a bug or a shortcoming (from me / lack of knowledge after nearly 35 years in the business).

Take into account my discovery of the ListBox modes !
(sorry Dave: I never noticed what you wrote. I do not have checked, but you were right: it was my fault / I was wrong.)

After understanding that, I ran an old (but regularly updated) multimedia project and I found that it was working fine as I use it: in the non default ListBox mode ! (just because I set the ColumnWidths in the ‘text’ file as integer values like 10,100,50,400). And because in that project I never have more columns that my screen is able to display (4 or 5 small columns !), I never noticed a display difference. After using the ListBox Control for so many years (15 Years ? Since CrossBasic !), I discovers some new thing in it ! (No, I do not added an horizontal scrollbar: not needed !).

PS: I’ve made a look around to the actually available IDEs and found they have a long, very long learning curve vs Xojo IDE.
Xojo IDE does not need intensive learning to start coding. Set a name to the new project and start coding (nearly)
Compare with XCode, NetBeand, Eclipse and so many others !

Michel_Bujardet · November 30, 2013, 10:45am

[quote=49969:@Emile Schwarz]are-you using Xojo as a skeleton and write your application(s) with declare where these are needed (Xojo have nothing to achieve what you want to do / have bug / is slow / whatever) ?
you are using Xojo as is (no Declare / no external plug-in / pure Xojo) ?[/quote]

I had to use Declare to obtain custom fonts. But apart from that my programs are pure Xojo. It would be counterproductive to use Xojo just with Declare, as XCode probably would do a better job at that, but it seems possible…

Emile_Schwarz · November 30, 2013, 10:47am

XCode probably would do a better job at that, but it seems possible…
If you learned to use that IDE

Better job ? Certainly.
Lower foot print application ? Certainly too.

Michel_Bujardet · November 30, 2013, 10:55am

[quote=49971:@Emile Schwarz]>XCode probably would do a better job at that, but it seems possible…
If you learned to use that IDE

Better job ? Certainly.
Lower foot print application ? Certainly too.[/quote]

I am not so sure small footprint is paramount today. I noticed that apps tend to inflate and nobody seems to care. So I am not concerned about that.

And sure, Xcode has an extremely steep learning curve, probably due in part to abstruse IDE. Personally, I gave up a while ago. I have developed in C# and C++, but I am not going to twist my brain into Xcode when I have Xojo at hand. I am not masochistic

Emile_Schwarz · November 30, 2013, 11:06am

What if Xojo add what I saw long time ago in some forgotten software:

add inline C or assembler or other type of code, inside a pure Xojo code (for speed critical sections or Xojo fat generated code) ?

BTW: a fat is a fat. Concerned ? If nobody cares (as it seems), why do I care ? I do not know, but I care and I cannot forgot that. Argh ! The more code your application have the more your application can potentially be bugged ? It may be that.

Now I recall an Apple //c assembler that was so good that it wrongly code some opcodes when it was so easy to test all of them, what I’ve done to find that bug. Nota: when I found that it was too late to report to the owning company because it was out of business.

Sam_Rowlands · November 30, 2013, 11:43am

[quote=49969:@Emile Schwarz]What I had in mind was:
are-you using Xojo as a skeleton and write your application(s) with declare where these are needed (Xojo have nothing to achieve what you want to do / have bug / is slow / whatever) ?
you are using Xojo as is (no Declare / no external plug-in / pure Xojo) ?[/quote]
Yes indeed.

For photo editing I mainly use Core Image, you basically build a chain of commands and then pass it off to be rendered, Core Image will then utilize what hardware it can and returned a processed image. It can be frustrating at times working with Core Image, because it’s a simple system, which has a lot of bad habits. Utilizing Core Image is a mixture of MBS and declares.

I use Core Graphics a lot, it has a lot more functionality than the standard graphics class. All Core Graphics code is 100% declares.

Icons in interface elements are loaded through my Retina Kit (Except HDRtist Pro as it’s still a Carbon app), which uses Declares to load up images in a way that the OS will automatically handle Retina for me when it’s needed.

I also use a lot of NSTypes such as NSDictionary and NSArray as these allow me to easily store the data in Property Lists and NSDictionary is almost like Xojo’s dictionary. Because I use a lot of CG, CI and Apple’s NSColorPicker, I tend to use NSColor more than the Xojo Color object. NSColor allows for greater precision and color spaces. I also use a lot of NSImages and CGImages, because these can be 128-Bit floating point.

HDRtist Pro:

Uses a custom C plugin to do some 32-bit floating point math (because it was much faster than native Xojo).
Uses a custom Image Unit for Core Image.
Uses declares into Apple’s Core Graphics & Core Image system (also uses the MBS plugin) to process the 128-Bit floating point images.
Uses a terminal app to provide image alignment.

Shine:

Uses Core Graphics and Core Image (CG 100% declares, CI partial declares and MBS plugin).
Uses Declares to get at native OS Controls such as Color Well, NSPopover, and to customize the window.
Uses On-the-fly generated Core Image filters (100% Declares), takes a OpenGL String and builds a CIKernel, then Builds a CIFilter.
Uses declares to load & display interface images as NSImages (giving it Retina compatibility).
Uses Declares for NSTypes and property lists (used as the document format), preferences, recent items.

Fun Greetings Deluxe:

Uses Core Graphics for the layout and for printing (100% Declares)
Uses Core Text for the text drawing, which is very powerful and flexible, but a PITA to work with (100% Declares).
Uses Declares for OS controls such as ColorWell, Round slider and rounded text fields.
Uses declares to load & display interface images as NSImages (giving it Retina compatibility).
Uses Declares for NSTypes and property lists (used as the document format), preferences, recent items.
Uses Core Image via declares for the Photo Effects.

App Wrapper Mini:

Uses Declares and MBS plugin to be compliant with Apple’s Resume functionality.
Uses Declares for NSTypes and property lists, preferences, recent items.
Uses Declares to get a NSScrollView.
Uses Core Graphics for some of the custom controls and the Icon editor.

Emile_Schwarz · November 30, 2013, 11:54am

Thank you Sam for your large and detailled (enough for the understanding) answer.

I will start to investigate that.

Sam_Rowlands · November 30, 2013, 1:53pm

You’re welcome.

The main thing to watch when using Declares is memory management, if this is mis-managed it will lead to crashes.