Why Static field can't be accessed through an instance.
Dart 2.4 Flutter 1.7 Android Studio 3.4
When I was trying to port codes from JAVA to Flutter(Dart), I got the compile error
I had defined the variable in MyMainBloc as follows
static LoginStatus loginStatus = null;
Then I create an instance:
MyMainBloc myApp;
I expect to use something like this: myApp.loginStatus, NOT MyMainBloc.loginStatus.
Static members of a particular class are accessed at the class level, not the object level. What this basically means is that the static variable is shared between objects.
With that in mind, what you are potentially attempting to do is probably not the best idea. Without seeing more of your code, you are probably better off declaring your loginStatus property as a private member on an encapsulating class, then accessing that member through a method (perhaps a standard get*() method).
The Oracle documentation on class members could be of some help here.
Related
Hi, I am quite a bit confused, why main method can access private fields.
void main() {
A obj = A();
obj._b = 'a';
print(obj._b);
}
class A {
String _b;
}
output:- a
please see the screenshot that theres no error.
Unlike Java, Dart doesn’t have the keywords public, protected, and private.
There's no keyword or annotation so you can declare a field/function as private on class level, but you can declare a field/function as private member on lib scope.Read
So lets come to your question, your main method is able to access a field started with '_' because there are in the same package. Create a new file and move your class to that file, and you will not be able to access the private member.
So,
identifiers that start with an underscore (_) are visible only inside the library.
In dart _ (underscore) sign is encapsulating fields on namespace level, not class level. For class level encapsulation ( still not private but protected ) consider using #protected annotation for the fields or move your class to a separate file.
I think this is the answer of you question right #umar_baloch.
I'm writing an AEM component and I have an object being returned that is a type from an SDK. This type has public properties and no getters. For simplicity, it might be defined like this:
class MyItem {
public String prop1;
public String prop2;
}
Now normally, I would need a getter, like so:
class MyItem {
public String prop1;
public String prop2;
public String getProp1() {
return prop1;
}
}
But I do not have this luxury. Right now, I've got a Java implementation that uses another type to resolve this, but I think it's sort of crazy that HTL doesn't allow me to just access prop1 directly (it calls the getter). I've reviewed the documentation and can't see any indication of how this could be done. I'd like to be able to write:
${item.prop1}
And have it access the public property instead of calling getProp1().
Is this possible?
You don't need getters for public fields if those fields were declared by your Java Use-class. There's actually a test in Apache Sling that covers this scenario:
https://github.com/apache/sling/blob/trunk/bundles/scripting/sightly/testing-content/src/main/resources/SLING-INF/apps/sightly/scripts/use/repopojo.html
This also applies to Use-classes exported from bundles.
For Sling Models using the adapter pattern [0] I've created https://issues.apache.org/jira/browse/SLING-7075.
[0] - https://sling.apache.org/documentation/bundles/models.html#specifying-an-alternate-adapter-class-since-110
From the official documentation
Once the use-class has initialized, the HTL file is run. During this stage HTL will typically pull in the state of various member variables of the use-class and render them for presentation.
To provide access to these values from within the HTL file you must define custom getter methods in the use-class according to the following naming convention:
A method of the form getXyz will expose within the HTL file an object property called xyz.
For example, in the following example, the methods getTitle and getDescription result in the object properties title and description becoming accessible within the context of the HTL file:
The HTL parser does enumerate all the public properties just like any java enumeration of public fuields which include getters and public memebers.
Although it is questionable on whether you should have public variable but thats not part of this discussion. In essence ot should work as pointed by others.
ConfigProperty.idPropertyMap is filled on the server side. (verified via log output)
Accessing it on the client side shows it's empty. :-( (verified via log output)
Is this some default behaviour? (I don't think so)
Is the problem maybe related to the inner class ConfigProperty.IdPropertyMap, java.util.HashMap usage, serialization or some field access modifier issue?
Thanks for your help
// the transfer object
public class ConfigProperty implements IsSerializable, Comparable {
...
static public class IdPropertyMap extends HashMap
implements IsSerializable
{
...
}
protected static IdPropertyMap idPropertyMap = new IdPropertyMap();
...
}
// the server service
public class ManagerServiceImpl extends RemoteServiceServlet implements
ManagerService
{
...
public IdPropertyMap getConfigProps(String timeToken)
throws ConfiguratorException
{
...
}
}
added from below after some good answers (thanks!):
answer bottom line: static field sync is not implemented/supported currently. someone/me would have to file a feature request
just my perspective (an fallen-in-love newby to GWT :-)):
I understand pretty good (not perfect! ;-)) the possible implications of "global" variable syncing (a dependency graph or usage of annotations could be useful).
But from a new (otherwise experienced Java EE/web) user it looks like this:
you create some myapp.shared.dto.MyClass class (dto = data transfer objects)
you add some static fields in it that just represent collections of those objects (and maybe some other DTOs)
you can also do this on the client side and all the other static methods work as well
only thing not working is synchronization (which is not sooo bad in the first place)
BUT: some provided annotation, let's say #Transfer static Collection<MyClass> myObjList; would be handy, since I seem to know the impact and benefits that this would bring.
In my case it's rather simple since the client is more static, but would like to have this data without explicitely implementing it if the GWT framework could do it.
static variables are purely class variable It has nothing to do with individual instances. serialization applies only to object.
So ,your are getting always empty a ConfigProperty.idPropertyMap
The idea of RPC is not that you can act as though the client and the server are exactly the same JVM, but that they can share the objects that you pass over the wire. To send a static field over the wire, from the server to the client, the object stored in that field must be returned from the RPC method.
Static properties are not serialized and sent over the wire, because they do not belong to a single object, but to the class itself.
public class MyData implements Serializable {
protected String name;//sent over the wire, each MyData has its own name
protected String key;
protected static String masterKey;//All objects on the server or client
// share this, it cannot be sent over RPC. Instead, another RPC method
// could access it
}
Note, however, that it will only be that one instance which will be shared - if something else on the server changes that field, all clients which have asked for a copy will need to be updated
I'm fairly new to GWT and have never worked with Java Servlets before. I know how to make RPCs but I was wondering if there are any concurrency issues with declaring member variables in my RPC's ServiceImpl/RemoteServiceServlet class. I.e. From multiple "simultaneous" RPCs overwriting the same variable, similar to what happens with threads when a variable isn't declared volatile.
I also need to use an extra thread in my server side code, so I was wondering if there's any problems (outside of the usual thread safety problems) with declaring some of the servlet's members as static so the other thread can access the variables without a reference to the servlet instance. Is it possible for more than one instance of the same RemoteServiceServlet class to be running at the same time?
E.g.
public class MyServiceImpl extends RemoteServiceServlet implements MyService {
// Which of these variable declarations are a bad idea in a servlet?
private String someVariable;
private static String anotherVariable;
volatile private static String multiThreadedVariable;
public void init() { ... }
...
}
Thanks.
A Servlet is a singleton, therefore there is only one instance of the MyServiceImpl class. By introducing these state variables you will run into thread-safety issues not because there might be more than one MyServiceImpl instance, but because there is only one instance that will service ALL of your requests. Unless you synchronize access to these variables, you will have thread-safety issues, so I recommend removing them completely (most likely you don't even need them).
I've got this
public static class MyClassHelper
{
DataContex db = new DataContext();
public static Type MyMethod()
{
//Do Something with db
// such as db.myTable
}
}
I'm getting the following error: "An object reference is required for the non-static field, method or property..."
Is there anyway to get around this?
How about this. I've an object that contains only integers, which is fine for all the internal functionings as it allows me to link tables. But occasionaly, I need to display some information to the user. That's why, I'd like to create a static method so it would read the integer, look up in the DB, and display a name instead of a number.
I want it to be a static method so that I can use it in my View template.
Thanks for helping
As #Oskar indicates your static method can't reference instance variables, only static variables. Rather than making the DataContext static, though, which would mean that it would exist for the life of the program, just create the DataContext as needed within the method. DataContext are best suited to a "unit of work" pattern and recreated as needed for just the task being accomplished rather than existing as a long-lived object. Be aware, too, that the DataContext is not thread-safe; you'll be creating some really hard to find errors unless you make all of your methods thread-safe. It's much simpler to just recreate the data context.
A static method can only see static members. Also, a static class can only have static member. You should mark your db as static:
static DataContext db = new DataContext();
Yep. You need to declare your DataContext to be static as well.