One small question: any good reason why there is no common interface for
TableModels? I have a few models implementing the same custom interface and before I can persist those custom interface objects I must cast them to TableModel because I can't define an interface like public interface ICommonTableModel extends TableModel because there is no base interface
@MFlisar no specific reason other than historical reasons. if I understand correctly, you have some contexts in which you're operating on instances of
ICommonTableModel, e.g. methods that accept them as arguments, but that context doesn't know that they're also TableModels? would an intersection type help you here? e.g. public void <T extends ICommonTableModel & TableModel> persistMyCommonTableModel(T item). this would be safer than a cast because it would only accept objects that are of both types. maybe I could answer your question a little better if you gave a more specific example. we could consider making interfaces like IModel and ITableModel in a future major version, but I am totally swamped with other projects right now and I don't have a good timeline for when a stable 4.0 might launch, so I want to be able to give you good suggestions that will help now
@sbosley this does work and that's what I do (although java forces you to first define the class and then the interface like
<T extends TableModel & ICommonTableModel>. I was just curious because I would prefer to define that my custom interface extends TableModel and then I can forget about it instead of defining the T type in all functions I write...
@MFlisar yep totally makes sense. another option you could try (and this is what we would do back when we didn't have a code generator and wrote models by hand) -- make an abstract class that extends TableModel instead of an interface, and then make your model objects extend from that class instead of from TableModel. this would require a code generator plugin, although probably not a complicated one
@jdkoren I wonder if we should make a first-class plugin to make it easier to define custom superclasses? or even just bake that functionality into the existing annotations? like in
@TableModelSpec we could have Class<? extends TableModel> superclass() default TableModel.class. this would require some dependency wrangling but might be useful...
I also see the appeal of defining some interfaces for our model objects but that's a big refactor to a lot of stuff, so I'm not sure if/when I could get to that
TableModel on its own is a pretty small interface, but the interface we'd actually need to pull out would be that of AbstractModel, which is huge, so we'd have to apply any such interface refactor to all things that touch AbstractModel, TableModel, or ViewModel. it would be a lot easier if we could use default methods on the interfaces, but it looks like Android currently only supports that on API 24+
anyways @MFlisar, thanks for the suggestion! I do like the idea of pulling out some of these interfaces and your use case makes sense, so I'll put it down as something to consider for our 4.0 version. in the meantime I definitely recommend using the intersection type approach (this is what I've always done for similar problems, although it's only come up once or twice which is part of why we've never done it any other way) or try the superclass approach
@Aranda I hacked one together using the org.json classes once. you can see a partial example in the unit test suite here, but this is a partial example using only a few select classes, so it's not very general. I implemented a more general one for another project at once using code generation to generate the boilerplate of constructing real objects from org.json, but I'm afraid that implementation isn't open sourced.
all that being said though, I'm told that GSON is compatible with j2objc (which makes total sense as they're both made by Google), although I have not tried integrating it into a project myself. if you can get it working though, it should be a great implementation of JSONMapper on both platforms. you can see an example of how I set it up for the android unit tests here
Another question: can I make a model implement an interface with multiple paramters?
Following
@TableModelSpec(className = "DesktopItem", tableName = "desktopItem")
@Implements(interfaceDefinitions = {@Implements.InterfaceSpec(interfaceClass=Item.class, interfaceTypeArgs={DesktopItem.class, Long.class})})
public class DesktopItemEntrySpecGenerates this:
public class DesktopItem extends AndroidTableModel implements Item<Long>So the generated class is missing the DesktopItem paramaeter in the interface...
@MFlisar for the return values of setters, there are a couple ways to do it using code generation plugins. the easiest way is probably to disable the default getters and setters using the
disableGettersAndSetters flag (documented here), and defining a new code generation plugin that scans the list of each model's properties and generates getters and setters using the interface that you would prefer. you can look at the BasicPropertyGeneratorclass to see how that class creates getter/setter definitions, and take inspiration from that.
as for using a class in the
@Implements.InterfaceSpec type args, the reason it's not working is because you can't refer to a class object of a generated class while you're generating that class -- it doesn't exist at compile time, so the annotation processing APIs can't pick up the package name. using the fully qualified class name is the correct solution, and that's why that option exists
Is it possible to overwrite a generated model method? Like following:
@ColumnSpec(name = "name", defaultValue = "")
String name;
@ModelMethod
public static String getName(CustomItem item) {
// custom code...
return ...;
}The ModelMethod will throw an exception because the generated model has this function already...
I know I can solve it by renaming the field name and then I can define my custom getName function, I'm just interested if there is a way to overwrite the generated method instead
@MFlisar ah I see, I thought you were referring to the generated model method, not the generated getter. in that case your only option is a code generation plugin. if I understand what you're trying to do correctly, you'd probably want a custom subclass of
TableModelSpecFieldPlugin as well as custom subclasses of the BasicPropertyGenerator classes for different field types, i.e. BasicStringPropertyGenerator, BasicLongPropertyGenerator, etc. your custom property generator subclasses could look for specific annotations on their fields and override methods such as getterMethodName or writeGetterBody in order to customize the implementation details of your accessors. (at this time you can't skip generating getters/setters entirely, but you could you just design your annotations such that they caused the getter to delegate to a private model method, or you could make the getter name different and the method private). you'd need to register your custom property generator classes with your subclass of TableModelSpecFieldPlugin by overriding the methods such as getStringPropertyGenerator and getLongPropertyGenerator. hope that makes sense!
Hi Everyone! I'm working on integrating Kotlin into an existing Android application that uses SquiDB. All of our spec classes (e.g.
@TableModelSpec) are currently written in Java. When I try to use one of these classes from Kotlin I get a symbol not found error from the compiler. Issues #278 and #166 seem related. What I'm wondering is if this is a supported use-case in SquiDB? Or would we need to do something like port our existing spec classes to Kotlin and use kapt?
hi @sonelliot! I believe that you can keep your models in Java and just use
kapt -- while I haven't done much with kotlin myself, my understanding is that you just need to use that to configure both java and kotlin annotation processing when using the kotlin plugin. I think this is the same issue as #278 -- I just realized that a user submitted a pull request to clarify the readme for this issue that I missed, I should get that in :) hope that helps! definitely post back here if things still seem amiss
Hi Guys, is suqidb working with xcode 9? We tried and we found an issue when we use the in Criterion. It looks like it looses the collection of values. I double checked the list multiple times and it has values.
[ERROR] : Task - unobservedException Optional("Index: 0, Size: 0")
java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at 0x0000000102b20cc2 java.util.ArrayList.get() + 110
at 0x000000010328b9a2 com.yahoo.squidb.sql.CompiledArgumentResolver.resolveSqlString() + 610
at 0x000000010328b1b2 com.yahoo.squidb.sql.CompiledArgumentResolver.resolveToCompiledStatement() + 114
at 0x0000000103015ba5 com.yahoo.squidb.sql.TableStatement.compile() + 213
at 0x0000000103015c41 com.yahoo.squidb.sql.TableStatement.compile() + 33
at 0x000000010314d387 com.yahoo.squidb.data.SquidDatabase.query() + 119
at 0x00000001032d3ed5 co.thefabulous.shared.data.source.HabitRepository.getById() + 405
[ERROR] : Task - unobservedException Optional("Index: 0, Size: 0")
java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at 0x0000000102b20cc2 java.util.ArrayList.get() + 110
at 0x000000010328b9a2 com.yahoo.squidb.sql.CompiledArgumentResolver.resolveSqlString() + 610
at 0x000000010328b1b2 com.yahoo.squidb.sql.CompiledArgumentResolver.resolveToCompiledStatement() + 114
at 0x0000000103015ba5 com.yahoo.squidb.sql.TableStatement.compile() + 213
at 0x0000000103015c41 com.yahoo.squidb.sql.TableStatement.compile() + 33
at 0x000000010314d387 com.yahoo.squidb.data.SquidDatabase.query() + 119
at 0x00000001032d3ed5 co.thefabulous.shared.data.source.HabitRepository.getById() + 405
based on the exception, I'd guess that when the arguments to the statement are resolved, the argument in the
in Criterion does not return true for instanceof java.util.Collection<?>. can you provide a brief code sample for how you're constructing the in Criterion? might help us to track down if there's some kind of bug with how j2objc translates things (I'm assuming this issue doesn't happen in java)
We had to change the ios native files to make it work
(some missing @property(copy))
ok, thanks! I've made some changes for j2objc 2.x on our dev_4.0 branch but have not tested with any versions of j2objc after 1.3.1. unfortunately I don't have access to a dev environment right now (moving this weekend and all my real computers are packed up) but I can take a closer look on monday
what were the
@property changes you needed to make? I don't think I encountered those when I was experimenting with j2objc 2
We create the Criterion in a very simple manner:
public List<Habit> getById(List<String> ids) {
SquidCursor<Habit> cur = db.query(Habit.class, Query.select(Habit.PROPERTIES).where(Habit.UID.in(ids)));
return habitCursorToList(cur);
}
thanks for the heads up about the
@property stuff. I'm not well versed in obj-c at all, what does that change do?
I'm assuming that it copies the values when assigning them but that seems like an odd necessity for strings, since strings should be immutable
I used copy just to make it work, not sure about it though
I wonder if that's a new thing in Xcode 9 that they introduced to guard against exactly that kind of bug. I'll definitely get those changes into our 4.0 branch
all
Lists should also be Collections though, since List extends Collection. I'll probably need to examine the translated code and do some debug stepping to track down the problem