Any reason to call the clases diferente between IOS and Android?

Data Abstract
,
1

Android : DataTable
IOS: DADataTable

That force an IFDEF and maybe can be avoid)?)

Will not be easier to share code if both clasess have the same name?

I have a ndroid app and now im doing the IOS app and fine that kind of questions, maybe is only me and im bad.

Best regards.

2

Im tryng to mimimize constructor and name incompatibilities with some like that. Still im not sire how will works.

  {$IFDEF IOS}
    DataTable = class(DADataTable)
      constructor(aTableName: String);
      begin
         //implement call creation with table name ala Android
      end;
    end;
    DataTableView = class(DADataAdapter)
    end;
    Briefcase = class(DABriefcase)
    end;
    RemoteDataAdapter = class(DARemoteDataAdapter)
    end;
    DataRow = class(DADataTableRow)
    end;    
    AesEncryptionEnvelope = class(ROAESEncryptionEnvelope)
      constructor;
      begin
          //implement call creation with password ala Android
      end;
    end;     
  {$ENDIF}

Any help will be apreciated.

3

Well, it’s not just the names that are different, the classes also hav vastly different APIs, because they follow the platform conventions, for Cocoa vs Java/Android, respectively. DA is designed from scratch for each platform, long predating Elements’ multi-platform support or the idea that you’d want to share the exact same code across platforms, i’m afraid.

We are looking at leptons for addressing that, long term, to give an (optimal) consistent API for DA that can be used in a cross-platform way with Elements — but i cannot comment on details ir timelines there, yet.

4

Im sure that will be a better approach to users tryint o the get same code between several plattforms, reducing ifdefs and work

5

Is in theory possible to build that classes using element and RTL and be compatible with all plattforms?

I know the day have 24 hours (LOL) just asking what do you think.

6

There’s two options we’re considering:

  1. a mapping layer, similar to Elements RTL or Sugar themselves, to provide a unified API over the existing per-platform DA implementations
  2. a new, sixth, DA client implementation in “native” cross-platform Elements code

i’m leaning towards option 2.

1 Like